> On Mar 15, 2016, at 12:32, Tanner Nelson via swift-evolution
> <[email protected]> wrote:
>
>
>> On Mar 15, 2016, at 1:54 AM, Charles Constant <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> +1 for junking the .self requirement
>>
>> On Wed, Mar 9, 2016 at 11:14 PM, David Hart via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>> I strongly agree for the removal of .self. I remember it being a great
>> source of confusion when I first learned Swift.
>>
>>
>> I had the same experience. It was very disorienting.
>>
>> Now that Dave and Joe have explained its origin as a safety feature, it
>> makes sense. The problem is that there's no way to convey that to the
>> end-user, so it seems like it has some deeper meaning. Then you start
>> second-guessing yourself if there's an error in your code, etc.
>
> I agree. Swift's type-checking engine is strong enough to merit not needing
> the redundant `.self` safety check. It feels like I'm doing something wrong
> when I need to use `.self`.
I do want to note one additional case that will become ambiguous:
let x = [NSURL] // value of type 'Array<NSURL.Type>', or 'Array<NSURL>.Type' ?
let y = [NSURL.self] // definitely the former
let z = [NSURL]() // definitely the latter
I think we have to treat this as the former, and I think the rule is just "if
the close bracket is immediately followed by an open paren, it's a type;
otherwise it's a value". This definitely affects what `[NSURL].foo` means, too
(is it a static or dynamic property?).
We could also restrict the array/dictionary shorthand syntax to type position,
but it seems like it's fairly conventional to use "let x = [NSURL]()".
Jordan
P.S. We actually have this problem today: does `NSURL?.self` have type
'Optional<NSURL.Type>' or 'Optional<NSURL>.Type' ?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
