> On Sep 29, 2017, at 4:03 PM, Taylor Swift <[email protected]> wrote:
>
>
>
> On Sep 29, 2017, at 5:56 PM, Dave Abrahams <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>
>>> On Sep 29, 2017, at 3:48 PM, Taylor Swift <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>
>>> On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Sep 29, 2017, at 1:23 PM, Taylor Swift <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Instead of
>>>>
>>>> buf.intialize(at: i, from: source)
>>>>
>>>> We want to force a more obvious idiom:
>>>>
>>>> buf[i..<n].intialize(from: source)
>>>>
>>>>
>>>> The problem with subscript notation is we currently get the n argument
>>>> from the source argument. So what would really have to be written is
>>>>
>>>> buf[i ..< i + source.count].initialize(from: source)
>>>>
>>>> which is a lot more ugly and redundant. One option could be to decouple
>>>> the count parameter from the length of the source buffer, but that opens
>>>> up the whole can of worms in which length do we use? What happens if n - i
>>>> is less than or longer than source.count? If we enforce the precondition
>>>> that source.count == n - i, then this syntax seems horribly redundant.
>>>
>>> Sorry, a better analogy would have been:
>>>
>>> buf[i...].intialize(from: source)
>>>
>>> Whether you specify the slice’s end point depends on whether you want to
>>> completely initialize that slice or whether you’re just filling up as much
>>> of the buffer as you can. It also depends on whether `source` is also a
>>> buffer (of known size) or some arbitrary Sequence.
>>>
>>> Otherwise, point taken.
>>>
>>> -Andy
>>>
>>> After thinking about this more, one-sided ranges might provide just the
>>> expressivity we need. What if:
>>>
>>> buf[offset...].initialize(from: source) // initializes source.count
>>> elements from source starting from offset
>>>
>>> buf[offset ..< endIndex].initialize(from: source) // initializes up to
>>> source.count elements from source starting from offset
>>>
>>>
>>> The one sided one does not give a full initialization guarantee. The two
>>> sided one guarantees the entire segment is initialized.
>>
>> In every other context, x[i...] is equivalent to x[i..<x.endIndex]
>>
>> I don't think breaking that precedent is a good idea.
>>
>>> For move operations, the one sided one will fully deinitialize the source
>>> buffer while the two sided one will only deinitialize endIndex - offset
>>> elements.
>>
>> —
>> -Dave
>
> well since people want to use subscript notation so much we need some way of
> expressing case 1. writing both bounds in the subscript seems to imply a full
> initialization (and thus partial movement) guarantee.
Presumably, in your use case, you’re working directly with buffers on both
sides (please point us to the real code). With the slicing approach, that would
be done as follows:
bufA[i ..< i + bufB.count].initialize(from: bufB)
That will enforce full initialization of the slice: precondition(self.count ==
source.count).
Your point stands that it is redundant. That point will need to be weighed
against other points, which I think should be discussed in another thread.
-Andy
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
