Sent from my iPad

> On Jun 2, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
> <[email protected]> wrote:
> 
> Isn't this the same argument for .dynamicType over type(of:) though?
> 
> Given that that debate has been settled in favor of the latter, I think the 
> question today is how best to come up with a consistent scheme.
> 
> Earlier in this conversation, it was pointed out (by Matt, I think?) that one 
> key advantage of type(of:) is that it takes on a syntax that is actually 
> possible to write in Swift, since one cannot extend Any.

Yep, IMO we should stick with the strategy that if something *looks* like a 
user-definable construct it should be possible to at least write the 
declaration even if it wouldn't be possible to implement.  That rules out 
static or instance properties or methods that apply to all types.

> 
> If we take this principle to its logical conclusion, properties (of a type or 
> instance) which apply to Any should be global functions.
> 
>> On Thu, Jun 2, 2016 at 16:26 Russ Bishop <[email protected]> wrote:
>> 
>>> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu <[email protected]> wrote:
>>> 
>>> 
>>> In the earlier conversation, it was pointed out (by Dave A., I think?) that 
>>> examples such as Array.size show how this solution can get confusing. And 
>>> even though there aren't fixed-length arrays in Swift, those may come one 
>>> day, making the syntax even more confusing.
>> 
>> 
>> Array.count is a function taking an instance; I’m not sure I agree it would 
>> be terribly confusing… then again I run in Xcode with the quick help pane 
>> open so I see the doc comments for every type, property, and function as I 
>> move around the code. It’s quite handy :)
>> 
>> I could see including memory in the name (or something similar) if we want 
>> to be extra clear about it.
>> 
>>     Int.memorySize
>>     Int.memoryAlignment
>> 
>> 
>> Ultimately the type’s size in memory is a property of the type so it seems 
>> clear that is where it belongs (being careful not to steal too much of the 
>> namespace of course).
>> 
>> 
>> Russ
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to