on Tue Jul 05 2016, Andrew Trick wrote:
>> On Jul 5, 2016, at 10:48 AM, Dave Abrahams via swift-evolution
>> wrote:
>>
>>> I want to call this out separately because it’s not specific to my
>>> proposal and changes the existing UnsafePointer API.
>>>
>
>>> Brent’s
> On Jul 5, 2016, at 10:48 AM, Dave Abrahams via swift-evolution
> wrote:
>
>> I want to call this out separately because it’s not specific to my
>> proposal and changes the existing UnsafePointer API.
>>
>> Brent’s suggestion is to change `initialize(from:count:)`
on Tue Jul 05 2016, Andrew Trick wrote:
>> On Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution
>> wrote:
>>
>> I have a pile of naming quibbles; rather than describe them all in
>> prose (which turned into a mess), I've
> On Jul 5, 2016, at 11:27 AM, Xiaodi Wu wrote:
>
> I'm not sure about that. "Initialize backward from x, count y" is unambiguous
> as to how initialization starts and iterates (the first argument), and it is
> clear that `count` is an end condition dissociated from
I'm not sure about that. "Initialize backward from x, count y" is
unambiguous as to how initialization starts and iterates (the first
argument), and it is clear that `count` is an end condition dissociated
from anything to do with how initialization starts and iterates.
By contrast, "Initialize
> On Jul 5, 2016, at 11:05 AM, Xiaodi Wu wrote:
>
> I don't mind `initialize(from:forwardToCount:)`, but I do have trouble with
> Brent's suggestion of `initialize(from:backwardFromCount:)`. It adds
> ambiguity as to whether the pointer in the first argument points to the
I don't mind `initialize(from:forwardToCount:)`, but I do have trouble with
Brent's suggestion of `initialize(from:backwardFromCount:)`. It adds
ambiguity as to whether the pointer in the first argument points to the 0th
element or the (count - 1)th element from which initializing is proceeding
> On Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution
> wrote:
>
> I have a pile of naming quibbles; rather than describe them all in prose
> (which turned into a mess), I've annotated parts of the "Full
> UnsafeRawPointer API" section in a gist:
>