<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">In the future, can you make each SE-**** into a link to the github page of the proposal?</div><div class=""><br class=""></div><div class="">Michael</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 5:27 PM, Alex Martini 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">To help keep proposals moving forward, the Swift core team has set aside some time specifically for design discussions of upcoming proposals. Below are some rough notes from the yesterday's discussion.<br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">These are <i class="">informal</i> comments, intended to guide the proposals in directions that draw constructive feedback. You are welcome to ignore the feedback, agree with it, or disagree with it. As always, the formal decision doesn't happen until after the review period ends.</div><div class=""><br class=""></div><div class=""><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px; font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">SE-0047<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0047" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">This is about switching the polarity of <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@warn_unused_result</span></tt> and renaming it to <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@discardable</span></tt> as something on the return type.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">Is there a subtype conversion? Is <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Void</span> <span class="pre">-></span> <span class="pre">Int</span></tt> a subtype or supertype of <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Void</span> <span class="pre">-></span> <span class="pre">Void</span></tt>? No, it’s not; we just have a special rule for closures.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">If we put this in the type system, we would want it to be a function attribute rather than a declaration attribute. It’s not obvious why it’s a bad idea to have this in the type system... It’s a little bit outside the bounds of what the type system normally does; it’s not that important of a semantic property.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">It looks like the proposal has an error in the second to last line before “Mutating Variants” – it should either be a hard error or nothing. Also the case below:</p><div class="highlight-python" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><pre style="overflow-x: auto; overflow-y: hidden; border: thin dotted rgb(12, 55, 98); margin-top: 0px; margin-bottom: 12px; padding: 0.8em; background-color: rgb(240, 240, 240);" class="">let x = f
x()
c = x()</pre></div><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">In the more general case, if <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">x</span></tt> is a closure...</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">How many cases are there where you want to mark the result as discardable so you don’t have to write <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">_</span> <span class="pre">=</span> <span class="pre">foo()</span></tt> to explicitly silence the warning about an unused result?</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">We almost certainly don’t want to allow overloading based on this. Does the propagation even work? If you have a compose operator that takes <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">T</span> <span class="pre">-></span> <span class="pre">U</span></tt> and <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">U</span> <span class="pre">-></span> <span class="pre">V</span></tt> and try to pass it a <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">T</span> <span class="pre">-></span> <span class="pre">discardable</span> <span class="pre">U</span></tt> you won’t get a <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">discardable</span> <span class="pre">V</span></tt> unless we make it a full qualifier in the type system.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">Ok... if we don’t make it part of the function type, where would we want the attribute to go? This is similar to how we place <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">inout</span></tt>. It would be similar to how we place <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@autoclosure</span></tt> but that attribute is currently not quite right.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">It would be consistent to put it on the function declaration. There are other places though where we might want attributes on the function type that are understood to not effect the actual function type, such as some kind of ownership rules.</p><div class="highlight-python" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><pre style="overflow-x: auto; overflow-y: hidden; border: thin dotted rgb(12, 55, 98); margin-top: 0px; margin-bottom: 12px; padding: 0.8em; background-color: rgb(240, 240, 240);" class="">func f () -> @discardable Int // we're saying this is valid
let x: () -> @discardable Int // but we wouldn't let you write this
func g() -> @convention(block) () -> () {...} // we wouldn't allow this either</pre></div><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">In that last case, you can put attributes on types. We like how putting the <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@discardable</span></tt> on the type because of how it reads, but it’s not on the type.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">Counterpoint: It’s actually more semantically part of the function. You don’t have a “discardable integer”, you have a function whose result is discardable.</p><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px; font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class=""><br class=""></h3><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px; font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">SE-0042<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0042" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">Right now if you access an instance method on a type, you get this curried thing that accepts “self” and then the members. It’s not useful for the standard library because they want flattened functions. And for mutable methods, because of how the in-out duration lasts, we end up with a miscompile that scribbles over random memory.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">Looking to the future, we can get operators on the type. Then operators would have the same type in both cases.</p><p style="text-align: justify; color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;" class="">We probably don’t need migration. If you wrote <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">#selector(foo</span> <span class="pre">as</span> <span class="pre">Bar)</span></tt> before, the <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Bar</span></tt> part will change. But that’s not very common and <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">#selector</span></tt> is still pretty new.</p></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="section" id="se-0043" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;" class="">SE-0043<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0043" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p style="text-align: justify;" class="">This seems like a simple generalization of our rules. People coming from the ML family would just expect this to work. It’s a resonable expectation.</p><div class=""><br class=""></div><div class=""><div class="section" id="se-0048"><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;" class="">SE-0048<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0048" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p style="text-align: justify;" class="">This is straightforward and 95% implemented. The contentious point is that it starts simple: you can’t add constraints to the type alias.</p><p style="text-align: justify;" class="">We want to avoid type-based metaprogramming.</p><p style="text-align: justify;" class="">Unclear if this would work:</p><div class="highlight-python"><pre style="overflow-x: auto; overflow-y: hidden; border: thin dotted rgb(12, 55, 98); margin-top: 0px; margin-bottom: 12px; padding: 0.8em; background-color: rgb(240, 240, 240);" class="">typealias StringDictionary<T> = Dictionary<String, T></pre></div><p style="text-align: justify;" class="">It need to infer that <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">T</span></tt> must be hashable. Maybe it’s only 85% implemented.</p><div class=""><br class=""></div><div class=""><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;" class="">SE-0049<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0049" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p style="text-align: justify;" class="">In short, <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@noescape</span></tt> and <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@autoclosure</span></tt> are attributes on the parameter. We got away with it before, but now that we’re requiring you to manually uncurry, you can’t write things that you used to be able to write. None of this makes sense; we should only accept these attributes in the type position.</p></div><div class=""><br class=""></div></div><div class="section" id="se-0049"></div></div></div><div class="section" id="se-0048" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"></div></div></div></div></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>