> On Sep 29, 2017, at 5:56 PM, Dave Abrahams <[email protected]> wrote:
>
>
>
>> On Sep 29, 2017, at 3:48 PM, Taylor Swift <[email protected]> wrote:
>>
>>
>>
>> On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <[email protected]> wrote:
>>>
>>>
>>>>> On Sep 29, 2017, at 1:23 PM, Taylor Swift <[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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
