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