So, what’s the difference between this and teaching Key Paths to look through tuple indices - that was the only part of your example I couldn’t directly express.
~Robert Widmann > On Jun 23, 2017, at 12:28 AM, Daryle Walker via swift-evolution > <swift-evolution@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. > > 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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution