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.
These are informal 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.
SE-0047 <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0047>
This is about switching the polarity of @warn_unused_result and renaming it to @discardable as something on the return type.
Is there a subtype conversion? Is Void -> Int a subtype or supertype of Void -> Void? No, it’s not; we just have a special rule for closures.
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.
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:
let x = f
x()
c = x()
In the more general case, if x is a closure...
How many cases are there where you want to mark the result as discardable so you don’t have to write _ = foo() to explicitly silence the warning about an unused result?
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 T -> U and U -> V and try to pass it a T -> discardable U you won’t get a discardable V unless we make it a full qualifier in the type system.
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 inout. It would be similar to how we place @autoclosure but that attribute is currently not quite right.
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.
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
In that last case, you can put attributes on types. We like how putting the @discardable on the type because of how it reads, but it’s not on the type.
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.
SE-0042 <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0042>
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.
Looking to the future, we can get operators on the type. Then operators would have the same type in both cases.
We probably don’t need migration. If you wrote #selector(foo as Bar) before, the Bar part will change. But that’s not very common and #selector is still pretty new.
SE-0043 <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0043>
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.
SE-0048 <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0048>
This is straightforward and 95% implemented. The contentious point is that it starts simple: you can’t add constraints to the type alias.
We want to avoid type-based metaprogramming.
Unclear if this would work:
typealias StringDictionary<T> = Dictionary<String, T>
It need to infer that T must be hashable. Maybe it’s only 85% implemented.
SE-0049 <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/MeetingNotes-03-15-2016.html#se-0049>
In short, @noescape and @autoclosure 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.