[swift-evolution] Proposal: Extend the &x -> UnsafePointer behavior to work with immutable values

[Joe Groff]

> On Dec 16, 2015, at 7:48 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 16, 2015, at 4:39 PM, Michael Gottesman via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Dec 16, 2015, at 4:30 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> On Wed, Dec 16, 2015, at 02:09 PM, Jacob Bandes-Storch wrote:
>>>> +1.
>>>>  
>>>> On Wed, Dec 16, 2015 at 11:44 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> # Alternatives
>>>>  
>>>> Do nothing and hope that at some point Swift introduces some form of first-class support for explicit immutable references. That's probably not happening any time soon.
>>>>  
>>>> What are you envisioning?
>>>  
>>> Not really envisioning much at the moment. Adding unsafe references would not be very good (and would be basically what we already have with UnsafePointer anyway). Personally I'm a big fan of Rust's lifetime system which allows for safe compile-time-checked references, but it does have a bit of a learning curve and is probably the most confusing part of Rust for newcomers, which is why I'm not proposing adding it to Swift as it would be incompatible with using Swift as a teaching language (I'm not sure how important that use-case is to the Swift core team but I know there's a lot of community interest there).
>> 
>> We have in the past spoken about having that be an opt in feature. But that would be down the line. It has some interesting properties such as guaranteeing that a value is thread local or that a value has a lifetime that is subsumed by a different lifetime so it does not need reference counting.
>> 
> 
> This is a bit of an aside, but I think a compelling use of an ownership system like Rust’s is the compiler guarantee that no code can unexpectedly store a reference to a mutable object (and potentially do something nasty with it later).

Some of these guarantees also arise naturally from value semantics; variables of pure value types can't be influenced outside their scope, and an 'inout' parameter can't capture a permanent reference and has a limited opportunity to mutate the original value.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/13a78028/attachment.html>