[swift-evolution] [Pitch] Object aliases

[Daryle Walker]

> On Jun 30, 2017, at 1:11 AM, John McCall <rjmccall at apple.com> wrote:
> 
>> 
>> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Swift is currently an alias-adverse language. The model for the equivalent of pointers is supposed to be for short-term use, and not persisted. Other constructs that would use references: read-write properties, read-write subscripts, and inout function parameters, can all be implemented by copy-in-then-copy-out, presumably to avoid alias dynamics and its anti-optimizations. So the scope of aliases here will be limited to local-scale renaming of object locations that the compiler can connect statically.
>> Yes, the use case is currently weak, but it is a stepping stone for stronger cases, like changing the interface of an object with (currently not in the language) strong type-aliases without copies.
>> 
> 
> We usually expect language features to stand on their own.  Certainly something as core as a new kind of declaration would be expected to.
> 
> Anyway, this feature is rather similar to what I called a "local ephemeral binding" in the ownership proposal, except that your alias does not access the referenced storage until it itself is accessed.  Unfortunately, this actually makes it *more* complex, rather than less, as it creates a new way to abstract over storage, including local storage.

I was thinking posing aliases would be like symbolic substitution; we could replace the alias with the text defining its source expression everywhere and there should be no efficiency change. But I would want any evaluation of the (sub-)object’s location to be computed once; is that where complexity could come in? I was hoping that object location determination could be done at compile-time; that’s the reason for restricting what kinds of objects can be a source object.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170630/1ed86a3b/attachment.html>