[swift-evolution] [Pitch] Object aliases

[John McCall]

> On Jun 30, 2017, at 4:55 AM, Daryle Walker <darylew at mac.com> wrote:
>> On Jun 30, 2017, at 1:11 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>>> 
>>> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.

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.

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.:

  var values: [Value]
  alias var count: Int = values.count
  alias subscript(i: Int) -> Value = values[i]

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170703/c20b0423/attachment.html>