> On 27 Apr 2017, at 09:41, Rien via swift-users <swift-users@swift.org> wrote:
>
>>
>> On 27 Apr 2017, at 09:54, Rick Mann <rm...@latencyzero.com> wrote:
>>
>>>
>>> On Apr 26, 2017, at 23:37 , Rien via swift-users <swift-users@swift.org>
>>> wrote:
>>>
>>> 1) When you obtain a pointer, it can no longer be ensured by the compiler
>>> that you won’t write to it.
>>> 2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’.
>>> I would not be surprised if the majority of ‘let’ constants never see any
>>> memory allocation at all.
>>
>> In my case, it's a field in a struct that's allocated elsewhere, and most
>> certainly exists, and is passed as a parameter, so it's 'let'. I really want
>> to be able to say "I promise I won't write to this", which seems reasonable
>> if the language is willing to give me an unsafe pointer in the first place.
>
> IIRC this is the reason for the mutable and non-mutable version of the
> pointer. With the non-mutable pointer you cannot write to the pointee.
> (At least not without some additional code)
> But it is another step entirely to then allow a let assignment to be used as
> the pointee. I assume the Swift team decided to keep things simple and not
> allow let’s to be used as pointee’s. It could probably be done in theory, but
> I imagine that to be a nightmare case for compiler writers...
The let constant may not even be stored in a single place; if it's known to be
constant it can be in-lined at the point of use and potentially unpacked and
dead code elimination throw away the unused members, for example.
If you want to pass in a let constant into the pointer, you can create a copy
of it locally in a local variable and then use that instead. However this will
be in the local scope, so the pointer isn't valid after it returns.
Alex
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
