[swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Taylor Swift]

okay, well until someone can come up with a subscript syntax that does what
we need it to do, I’m inclined to view at:from: in the function parameter
list as the clearest and most straightforward syntax. We shouldn’t use the
square brackets for the sake of using square brackets.

On Sat, Sep 30, 2017 at 6:51 PM, Dave Abrahams <dabrahams at apple.com> wrote:

> I don't think I made any arguments that could be viewed as pointing out a
> problem with the slice approach, unless you take as given the idea that the
> slice approach should mean something novel and unprecedented. I don't see
> the whole/part implication that you see in the two notations, even though I
> understand why you want to read it that way, in particular *because* of
> the precedent I cited.
>
> On Sep 30, 2017, at 4:23 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
> yeah, which is why I think the at:from: system is better than any
> subscript alternative. I know everyone wants to use the square brackets but
> it just doesn’t work very well for exactly the reasons you mentioned.
>
> On Sat, Sep 30, 2017 at 6:07 PM, Dave Abrahams <dabrahams at apple.com>
> wrote:
>
>>
>>
>> On Sep 29, 2017, at 4:03 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>>
>>
>>
>> On Sep 29, 2017, at 5:56 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>
>>
>>
>> On Sep 29, 2017, at 3:48 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>>
>>
>>
>> On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <atrick at apple.com> wrote:
>>
>>>
>>>
>>> On Sep 29, 2017, at 1:23 PM, Taylor Swift <kelvin13ma at gmail.com> 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.
>>
>>
>> Yes, I understood your reasoning.  Do you understand why I still don't
>> want to proceed in that direction?
>>
>> —
>> -Dave
>>
>>
>>
>>
>>
>>
>
> —
> -Dave
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170930/261e9af0/attachment.html>