[swift-evolution] [Pitch] Object aliases

[Nevin Brackett-Rozinsky]

This sounds similar to lenses. Have you looked at previous lens discussions
on-list?

Nevin


On Fri, 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
>    - 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
>
> 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.
> 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_opt**pose*
> *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/20170623/c2ddb4dc/attachment.html>