+1 A simple “discardable” would be great. If the result is Bool and “discardable” is placed right in front of it, it’s not only more readable but also eliminates the redundant word “Result”. Also no at sign is great.
Plus, this is super-straightforward to convert for the compiler when upgrading. R+ Sent from my iPhone > On 15 Oct 2017, at 15:52, Mike Kluev via swift-evolution > <swift-evolution@swift.org> wrote: > >> On 15 October 2017 at 14:23, Geordie Jay <geo...@gmail.com> wrote: >> Hi Mike, >> >> 2017-10-15 14:55 GMT+02:00 Mike Kluev <mike.kl...@gmail.com>: >>>> On 15 October 2017 at 13:35, Geordie Jay <geo...@gmail.com> wrote: >>>> Also we're not talking about whether the Bool itself is discardable. For >>>> example, it makes no sense to write: >>>> >>>> let something: discardable Bool = true >>> >>> you can't write this either: >>> >>> let something: inout Bool = true >>> >>> that doesn't mean "inout" should be "@inputOutput" before the parameter >>> name in function signature. >> >> This is a different case: inout is an annotation on argument types (of which >> there can be many). > > i mean: > > @discardableResult func foo(@inputOutput x: Int, @inputOutput y: Float) -> > Bool > > vs: > > func goo(x: inout Int, y: inout y) -> discardable Bool > > i deliberately mixed the current @discardableResult syntax with a > hypothetical "consistent" @inputOutput syntax to make my point more clear. to > me these use cases are virtually the same, and syntax shall be consistent > among them. > >> I don't understand what you're saying here. "Now in swift 0.0"? The first >> public version of Swift had this same functionality in its same form, with >> the name @warn_unused_result. The current version is just reversed, which to >> me is a logical change. > > in other words: "if we didn't have swift already what would I do" kind of > test. similar to the one that we already officially use: "if it wasn't done > already, would we do it now" to prune rarely used language constructs. > > remember the evolution of the "inout" keyword: > > (inout x: Int) ---> "var parameters dropped" + (x: inout Int) > > similarly, it's not unimaginable to consider this evolution as well: > > "@warn_unused_result func" --> "@discardableResult func" --> "func foo() -> > discardable Bool" > >>> throwing func foo() -> Bool >> >> I personally like that syntax, because that's exactly how I talk about such >> a function. "oh that's a throwing function so you need to call it with try". > > you are the first who +1-ed it so far, so we now have +2 in total for > "throwing". > >> As an extension to that, I'd also say "you can call that function without a >> preceding variable assignment because it has a discardable result". I would >> never say "this function returns a discardable boolean" because that just >> doesn't match my mental model of what's going on. To me, it's the function >> whose return value can be discarded — in theory it has nothing to do with >> the result itself. But it's quite possible I'm in the minority here. > > to me it's trivial: > > func foo() -> Bool - means "function foo returning result of type Bool" > > ditto: > > func foo() -> discardable Bool - means "function foo returning result of > type Bool that can be unused by the caller" > > very compatible with: > > foo(x: inout Bool) - means input / output parameter x that is of type Bool > > if you don't complain about the latter (like: "how come Bool is input > output?! it is the parameter that is input / output, not the Bool itself !!!" > or, similarly: "how come the function returns type Never? the function just > never returns but the type shall be Void !!!") then I don't see why you don't > accept the former. > >> But it's quite possible I'm in the minority here. > > as a matter of fact, so far it looks I am :) > > Mike > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
