<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 15, 2016, at 12:32, Tanner Nelson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 15, 2016, at 1:54 AM, Charles Constant <<a href="mailto:charles@charlesism.com" class="">charles@charlesism.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">+1 for junking the .self requirement<div class=""><br class=""><div class="">On Wed, Mar 9, 2016 at 11:14 PM, David Hart via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I strongly agree for the removal of .self. I remember it being a great source of confusion when I first learned Swift.<div class=""><div class="h5"><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I had the same experience. It was very disorienting. </div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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`.</div></div></div></div></blockquote><br class=""></div><div>I do want to note one additional case that will become ambiguous:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>let x = [NSURL] // value of type 'Array<NSURL.Type>', or 'Array<NSURL>.Type' ?</div><div>let y = [NSURL.self] // definitely the former</div><div>let z = [NSURL]() // definitely the latter</div></blockquote><br class=""><div class="">I think we have to treat this as the former, and I <i class="">think</i> 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?).</div><div class=""><br class=""></div><div class="">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]()".</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. We actually have this problem today: does `NSURL?.self` have type 'Optional<NSURL.Type>' or 'Optional<NSURL>.Type' ?</div></body></html>