> On Jun 30, 2017, at 1:11 AM, John McCall <rjmcc...@apple.com> wrote: > >> >> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
