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