<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jun 30, 2017, at 4:55 AM, Daryle Walker <<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 30, 2017, at 1:11 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><span style="font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">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 </span><code class="" style="font-size: 14px; -webkit-print-color-adjust: exact; margin: 0px 2px; padding: 0px 5px; white-space: nowrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">inout</code><span style="font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""> 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.</span></div><div class=""><p class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);">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.</p></div></div></div></blockquote><div class=""><br class=""></div>We usually expect language features to stand on their own. Certainly something as core as a new kind of declaration would be expected to.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div></div>I'm always wary of features that require a ton of restrictions because they can only be implemented using a sort of preprocessing. Among other things, it suggests that they cannot possibly be made resilient.<div class=""><br class=""></div><div class="">I think a better way of thinking of your feature is as sugar on top of the generalized accessors feature from ownership — that is, a concise way to declare a var/subscript with accessors that automatically forward to some other entity, e.g.:</div><div class=""><br class=""></div><div class=""> var values: [Value]</div><div class=""> alias var count: Int = values.count</div><div class=""> alias subscript(i: Int) -> Value = values[i]</div><div class=""><br class=""></div><div class="">John.</div></body></html>