[swift-evolution] [Pitch] Object aliases

[John McCall]

> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I started a thread earlier this week about strong type-aliases and object aliases. Here’s a fuller proposal on object aliases.
> 
> Feature name
> Proposal: SE-NNNN <file:///Users/daryle/NNNN-local-object-aliases.md>
> Authors: Daryle Walker <https://github.com/CTMacUser>, Author 2 <https://github.com/swiftdev>
> Review Manager: TBD
> Status: Awaiting review
> During the review process, add the following fields as needed:
> 
> Decision Notes: Rationale <https://lists.swift.org/pipermail/swift-evolution/>, Additional Commentary <https://lists.swift.org/pipermail/swift-evolution/>
> Bugs: SR-NNNN <https://bugs.swift.org/browse/SR-NNNN>, SR-MMMM <https://bugs.swift.org/browse/SR-MMMM>
> Previous Revision: 1 <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md>
> Previous Proposal: SE-XXXX <file:///Users/daryle/XXXX-filename.md>
> Introduction
> This is a proposal to define aliases to objects.
> 
> Swift-evolution thread: 1 <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037631.html>
> Motivation
> Aliasing allows a named object to actually refer to another object instead of newly-allocated storage. Referring to an object with a simple name isn't very useful, but referring to an object needing a complex expression to point to it can help with reducing typing.
> 
> However, aliasing has a cost. Compilers have to make certain assumptions if objects can have multiple names referring to them, and these assumptions reduce what kinds of optimizations can be made.
> 
> Language design can make a difference in how code can be optimized. Languages like C and C++ assume aliasing is allowed by default, limiting how many optimizations can be done. More recent versions of C have a keyword ("restrict") to ban certain objects from aliasing. Other languages go the other way; you need to take extra measures to alias objects, since object handling bars aliasing by default.
> 
> 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.

John.
> Proposed solution
> The solution is to introduce a new kind of object declaration. It uses a new keyword pose in the same place as let or var. It must be initialized with an expression that specifies an object, and be typed with a layout-compatible type (like the unsafeBitCast function).
> 
> struct Sample {
>     var test1 = (1, 2, 3, "apple")
>     //...
>     func trial1() {
>         pose firstTestNumber = test1.0
>         print(firstTestNumber)  // prints "1"
>         //...
>         firstTestNumber = 4
>         print(test1.0)  // prints "4"
>     }
> }
> When an object is used, the compiler associates the object with some sort of location ID. An alias just reuses its original's ID instead of having one of its own.
> 
> Here, the substitution is simple, but longer chains are imaginable. With a local-scope limitation, aliases work kind-of like macro constants in C.
> 
> Detailed design
> Add to the "Grammar of a Declaration":
> 
> declaration → alias-declaration
> Add a new section "Grammar of an Alias Declaration":
> 
> alias-declaration → attributes_opt declaration-modifiers_optpose pattern-initializer-list
> An alias declaration can only be in the local scope of a function. Expressions that describe source objects must be:
> 
> a named object, including function parameters
> a member of a qualifying tuple object
> a stored property of a qualifying struct (or class?) object
> A source object must have a lifetime at least as long as any aliases to it. A source object cannot have willSet and/or didSetobservers. The alias poses as an object of its type annotation, defaulting to the source object's type if omitted. An annotation must be of the source object's type or a layout-compatible type. An alias has the same mutability status as its source object.
> 
> An alias has the same operations as its annotated type, using the storage of the source object. An alias used as an inout function argument is banned if it and at least one other inout argument share memory (in whole or in part).
> 
> Since source objects are restricted to have their storage established statically, the compiler can reuse a source object's location ID when an alias to that source is referenced. Since an alias doesn't escape its containing function (any returns or inout action would copy to/from the source object), additional global aliasing checks are avoided.
> 
> Source compatibility
> Besides the new keyword pose, which should be conditional if possible, the changes are additive. I don't think it is legal to currently use an identifier pose in its planned syntax, so there should be no code to migrate.
> 
> Effect on ABI stability
> The effects of aliases happen only during translation, reusing locations of either named objects or a sub-objects of named objects. Since they shouldn't escape the function containing them (and can't be sub-objects of another type), the ABI should be unaffected.
> 
> Effect on API resilience
> Since aliases shouldn't leak out from being a function implementation aid, there should be no effect on the API.
> 
> Alternatives considered
> The alternative is to do nothing. This would currently make reuse of a sub-object for read-write a bit more wordy. But this facility may be more useful if making interface-wise different but layout-compatible types (like strong type-aliases) is added.
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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