True, that makes sense. I was simply trying to explore different possibilities of how these things could be represented in the syntax. What about #type(d) for static (declaration) type and type(v) for dynamic (value/instance) type? Or would that be potentially confusing as well?
The reason why I dislike .dynamicType etc. declarations is because they introduce another ‘magic’ properties to instances. I think that this functionality is very important and that it should be represented by the standard library instead. If Swift had a universal base type, one could say that the magic properties are just part of that base type (and by extension, part of the standard library), however, right now, they are injected by the compiler. I’d rather have a standard function like type: (Any)->AnyType for this purpose. Hell, I would even say that dynamicType(self) is an improvement over self.dynamicType :) — Taras > On 15 Apr 2016, at 09:54, Andrey Tarantsov <[email protected]> wrote: > >> I do not think that I was conflating these two aspects. Using #type(self) >> would return the particular type of the current instance (dynamic type) >> while using #type(A.var) would return the declared (static) type of the >> property. > > Taras, to me personally, #something suggests evaluation at compilation time, > so I would be *extremely* surprised if #type would return a dynamic type, and > #dynamictype is just an abomination, in every way worse than > something.dynamicType. > > A. > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
