Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David Sweeris via swift-evolution]

> On Oct 20, 2017, at 22:18, Eagle Offshore  wrote:
> 
> 
>> On Oct 20, 2017, at 2:55 PM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> how else are we supposed to express nuances when the language’s default is 
>> wrong for the code in question?
> 
> Fix the defaults?

K, then how do you express nuances where the “fixed” defaults are wrong?

> Honestly, I'm not sure how I've been programming for so long (30+ years) 
> without having to add half a dozen annotations to every single declaration.

Different languages offer different levels of “compiler smarts”, and have 
different mechanisms for exposing said “smarts”. What language(s) are you used 
to?

> "If you think C++ is not overly complicated, just what is a protected 
> abstract virtual base pure virtual private destructor and when was the last 
> time you needed one? 
> — Tom Cargill"
> 
> 
> Same applies to Swift at this point.  Its jumped the shark on annotations.

I think @discardableResult is the only one that’s generally used much in 
non-library code... There’s an annotation to specify the inlining behavior for 
when you don’t want the compiler making that decision, and one for something 
about transparency in the stdlib (I don’t think it’s part of the “public” 
language, though, because it starts with a “_”). I wouldn’t be too surprised if 
I’ve missed something, but AFAIK, Swift currently only has those two or three.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

> On 21 Oct 2017, at 17:06, Chris Lattner  wrote:
> 
> FWIW, I’d be pretty opposed to making Void? implicitly discardable.  In the 
> case of a generic function that returns T? where T can sometimes be void, the 
> optional still carries information: perhaps about failure of the operation or 
> something else.  The reason that void and Never default to being ignored is 
> that they are carry no information.   Void? carries one important bit.

Very well said.

For that same reason “return void-expression” shall not be allowed (and not 
parsed as such in a multiline statement)?

override func viewDidLoad() {
super.viewDidLoad()
return

someView = SomeView(frame: view.bounds)

}

Although it doesn’t fully solve the problem, as the two types may well be 
something other than void.

Mike

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Chris Lattner via swift-evolution]

> On Oct 18, 2017, at 8:04 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I am not sure this is entirely wise, for a few reasons.
> 
> a) I sure don't know why you'd want to return `Void?`, but if you do, it 
> doesn't follow that it should be discardable simply because `Void` is 
> discardable. It may well be so, or it may be (for some odd reason) that it's 
> the return type of a pure function that certainly shouldn't be discardable.

FWIW, I’d be pretty opposed to making Void? implicitly discardable.  In the 
case of a generic function that returns T? where T can sometimes be void, the 
optional still carries information: perhaps about failure of the operation or 
something else.  The reason that void and Never default to being ignored is 
that they are carry no information.   Void? carries one important bit.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

> On 20 Oct 2017, at 23:55, David Sweeris  wrote:
> 
>>   In any case, I think the “very high bar” we have now for breaking source 
>> compatibility makes it unlikely to change at this point

It’s not necessarily a source breaking change as both notations can be 
supported for a few versions and the older one gradually phased out via the 
deprecation warnings.

Mike


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Eagle Offshore via swift-evolution]

> On Oct 20, 2017, at 2:55 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> how else are we supposed to express nuances when the language’s default is 
> wrong for the code in question?

Fix the defaults?

Honestly, I'm not sure how I've been programming for so long (30+ years) 
without having to add half a dozen annotations to every single declaration.

"If you think C++ is not overly complicated, just what is a protected abstract 
virtual base pure virtual private destructor and when was the last time you 
needed one? 
— Tom Cargill"

Same applies to Swift at this point.  Its jumped the shark on annotations.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David Sweeris via swift-evolution]

> On Oct 20, 2017, at 10:54, Eagle Offshore via swift-evolution 
>  wrote:
> 
> +1
> 
> I really feel like the number of modifiers and decorators and annotations 
> etchas reached the point of illegibility.
> 
> It purpose="intensifier">reallyridiculous
> 
> That's what trying to read swift is getting to be like.
> 
> Trying to make every single nuance explicit is a fool's errand and is killing 
> readability.

Agree that annotations can get unwieldy, but how else are we supposed to 
express nuances when the language’s default is wrong for the code in question?

> Also, the choice to discard a result is properly the provenance of the 
> caller, not an intrinsic feature of a function.

Was that position argued during the proposal review? I don’t remember... In any 
case, I think the “very high bar” we have now for breaking source compatibility 
makes it unlikely to change at this point (OTOH, I’m frequently wrong here)

> I'll stop now.

Feel free to voice your concerns... Obviously I can’t promise anyone will agree 
or anything, but if you think you have a point that hasn’t already been 
discussed, we want to hear it! (Or at least I do... I’m just a random dude on 
the internet and don’t “speak for the list” or anything, but that’s been the 
general attitude as long as I’ve been hanging out here)

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Eagle Offshore via swift-evolution]

+1

I really feel like the number of modifiers and decorators and annotations 
etchas reached the point of illegibility.

Itreallyridiculous

That's what trying to read swift is getting to be like.

Trying to make every single nuance explicit is a fool's errand and is killing 
readability. 

Also, the choice to discard a result is properly the provenance of the caller, 
not an intrinsic feature of a function.

I'll stop now.

> On Oct 15, 2017, at 5:35 AM, Geordie Jay via swift-evolution 
>  wrote:
> 
> I've always read it (frustratingly) as e.g. "func throws Bool", which it 
> doesn't, it throws an Error.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Xiaodi Wu via swift-evolution]

On Thu, Oct 19, 2017 at 08:59 Mike Kluev  wrote:

> On 19 October 2017 at 08:52, Xiaodi Wu  wrote:
>
>> No, I'm talking about the implicit discardability proposed by Brent, such
>> as for all Optional<@discardable T>.
>>
>> He proposes that the @discardable syntax has a strong motivating
>> advantage because it can be extended in a way to mark _types_ so that
>> return values of those types are always implicitly @discardable. That is:
>>
>> @discardable class A { ... }
>> // any return value of type A is implicitly discardable
>> // what happens if A : Error and I throw A?
>>
>> class B : A { ... }
>> // is any return value of type B also implicitly discardable?
>
>
> "discardable" only apply to return types, similar to how "inout" only
> applies to "parameter types"
> (e.g. you can't make "func foo(x: Optional)"
>

Of course. That’s not the concern.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 19 October 2017 at 08:52, Xiaodi Wu  wrote:

> No, I'm talking about the implicit discardability proposed by Brent, such
> as for all Optional<@discardable T>.
>
> He proposes that the @discardable syntax has a strong motivating advantage
> because it can be extended in a way to mark _types_ so that return values
> of those types are always implicitly @discardable. That is:
>
> @discardable class A { ... }
> // any return value of type A is implicitly discardable
> // what happens if A : Error and I throw A?
>
> class B : A { ... }
> // is any return value of type B also implicitly discardable?


"discardable" only apply to return types, similar to how "inout" only
applies to "parameter types"
(e.g. you can't make "func foo(x: Optional)"

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Xiaodi Wu via swift-evolution]

No, I'm talking about the implicit discardability proposed by Brent, such
as for all Optional<@discardable T>.

He proposes that the @discardable syntax has a strong motivating advantage
because it can be extended in a way to mark _types_ so that return values
of those types are always implicitly @discardable. That is:

@discardable class A { ... }
// any return value of type A is implicitly discardable
// what happens if A : Error and I throw A?

class B : A { ... }
// is any return value of type B also implicitly discardable?


On Thu, Oct 19, 2017 at 01:02 Mike Kluev  wrote:

> On 19 October 2017 at 05:04, Xiaodi Wu  wrote:
>
>>
>> d) Does a class that override a `@discardable` type inherit that
>> annotation? If not, they it's kind of a weird exception to the inheritance
>> thing, no? If so, then we'd need a @nondiscardable annotation to do
>> type-level overrides of @discardable.
>>
>>
> the very current form of @discardableResult as a function attribute leads
> to these type of questions in the first place. if it was a type modifier -
> there would be no doubt:
>
> class A {
> func foo() -> Bool {
> ...
> }
>
> func bar() -> discardable Bool {
> ...
> }
> }
>
> class B: A {
> override func foo() -> discardable Bool { // ok, types compatible
>...
> }
>
> override func bar() -> Bool { // error. types mismatch
> ...
> }
> }
>
> Mike
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 19 October 2017 at 05:04, Xiaodi Wu  wrote:

>
> d) Does a class that override a `@discardable` type inherit that
> annotation? If not, they it's kind of a weird exception to the inheritance
> thing, no? If so, then we'd need a @nondiscardable annotation to do
> type-level overrides of @discardable.
>
>
the very current form of @discardableResult as a function attribute leads
to these type of questions in the first place. if it was a type modifier -
there would be no doubt:

class A {
func foo() -> Bool {
...
}

func bar() -> discardable Bool {
...
}
}

class B: A {
override func foo() -> discardable Bool { // ok, types compatible
   ...
}

override func bar() -> Bool { // error. types mismatch
...
}
}

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Xiaodi Wu via swift-evolution]

On Wed, Oct 18, 2017 at 9:29 PM, Brent Royal-Gordon 
wrote:

> On Oct 9, 2017, at 11:02 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This idea was discussed long ago and the present design was selected.
>
>
> But this design was discussed in the proposal as a "future direction",
> because @discardableResult was chosen partially because it was easier to
> implement. It says so [in the proposal][1]. This is why we write formal
> proposals, Xiaodi—so we remember why we made the decisions we made.
>

You're right that it was chosen in part because it was easier to implement.

But this does not at all mean that "@discardable" is the blessed future
direction; whether it is wise ever to adopt the "@discardable" design was
not thoroughly evaluated--it was simply decided that, for Swift 3,
@discardableResult was preferable to @discardable in the totality of things.

In my view, this means the "@discardable" idea needs to meet a higher bar
than a never-before presented idea, not a lower one.


>
* * *
>
> Now, the proposal specifically suggests we delay `@discardable` "until
> such time as there's a strong motivation to use such an approach". Do we
> have such a motivation?
>
> I actually think we do (although it may not be strong enough). Currently,
> we have two types—`Void` (as well as optionals, of any depth, wrapping
> `Void`) and `Never`—which are "implicitly discardable". That is, you don't
> need to mark a function which returns those types with
> `@discardableResult`; it inherently is. This is currently handled with [an
> ad-hoc test][2], but I think we should consider strengthening and opening
> up this mechanism.
>
> Why? Because there are other types we would like to be implicitly
> discardable. You can already make an argument for types like `Array`,
> but concurrency will bring types like `Future` which could get pretty
> strong benefits from it. Since we're planning to leave a lot of async stuff
> to userspace, there ought to be a userspace way to mark types as implicitly
> discardable. And if discardability stems from the type system, it's pretty
> natural to make ad-hoc discardibility a property attached to the type, too.
>
> (We could then mark `Never` with @discardable, make tuples discardable
> unless one of their elements is not discardable, make optionals discardable
> if the type they wrap is discardable, and—et voilà!—we have a nice, general
> language feature with as little magic as we can manage.)
>
> [1]: https://github.com/apple/swift-evolution/blob/master/
> proposals/0047-nonvoid-warn.md#future-directions
> [2]: https://github.com/apple/swift/blob/e907031d3d4555e917ca3ad7fffeac
> 7f580331a0/lib/Sema/TypeCheckStmt.cpp#L991
>


I am not sure this is entirely wise, for a few reasons.

a) I sure don't know why you'd want to return `Void?`, but if you do, it
doesn't follow that it should be discardable simply because `Void` is
discardable. It may well be so, or it may be (for some odd reason) that
it's the return type of a pure function that certainly shouldn't be
discardable.

b) Based on (a), I don't think that types composed of discardable types are
therefore discardable. I need to think this through further.

c) If you reject (b), then this brings up a larger issue.
`@discardableResult` is an attribute of the function; here, you're saying
that not only should the _spelling_ be moved to the other side of the
function arrow, but that the attribute should apply to the type. Would we
then have to invent a new overriding attribute for functions that return
`@discardable` types which don't want their return value to be discardable?
Like, a `@nondiscardableResult func foo() -> Void? /* implicitly
discardable type */`? I think this further demonstrates how it's not really
the type but the function that we want to annotate.

d) Does a class that override a `@discardable` type inherit that
annotation? If not, they it's kind of a weird exception to the inheritance
thing, no? If so, then we'd need a @nondiscardable annotation to do
type-level overrides of @discardable.

e) `Never` was explicitly designed to have no magic that any other
uninhabited enum would not get. To stick with this design, every enum
without any cases would have to be implicitly `@discardable`. This might be
surprising.

f) Speaking of enums: if types are discardable, then some errors are
discardable. By contrast, we do not currently have a `@discardableError`
annotation. What does it mean if a function throws a "discardable error"?
Can we choose not to catch it?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Brent Royal-Gordon via swift-evolution]

> On Oct 9, 2017, at 11:02 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This idea was discussed long ago and the present design was selected.

But this design was discussed in the proposal as a "future direction", because 
@discardableResult was chosen partially because it was easier to implement. It 
says so [in the proposal][1]. This is why we write formal proposals, Xiaodi—so 
we remember why we made the decisions we made.

* * *

Now, the proposal specifically suggests we delay `@discardable` "until such 
time as there's a strong motivation to use such an approach". Do we have such a 
motivation?

I actually think we do (although it may not be strong enough). Currently, we 
have two types—`Void` (as well as optionals, of any depth, wrapping `Void`) and 
`Never`—which are "implicitly discardable". That is, you don't need to mark a 
function which returns those types with `@discardableResult`; it inherently is. 
This is currently handled with [an ad-hoc test][2], but I think we should 
consider strengthening and opening up this mechanism.

Why? Because there are other types we would like to be implicitly discardable. 
You can already make an argument for types like `Array`, but concurrency 
will bring types like `Future` which could get pretty strong benefits 
from it. Since we're planning to leave a lot of async stuff to userspace, there 
ought to be a userspace way to mark types as implicitly discardable. And if 
discardability stems from the type system, it's pretty natural to make ad-hoc 
discardibility a property attached to the type, too.

(We could then mark `Never` with @discardable, make tuples discardable unless 
one of their elements is not discardable, make optionals discardable if the 
type they wrap is discardable, and—et voilà!—we have a nice, general language 
feature with as little magic as we can manage.)

[1]: 
https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md#future-directions
[2]: 
https://github.com/apple/swift/blob/e907031d3d4555e917ca3ad7fffeac7f580331a0/lib/Sema/TypeCheckStmt.cpp#L991

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Chris Lattner via swift-evolution]

> On Oct 15, 2017, at 5:55 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> On 15 October 2017 at 13:35, Geordie Jay  > 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.
> 
> my litmus test is: "if we did it now in swift 0.0 what would we do". 
> discardable before type passes this test, @discardableResult before function 
> doesn't.
>  

FWIW, the official litmus test for Swift 5 is explained here:
https://github.com/apple/swift-evolution/ 


-Chris



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[C. Keith Ray via swift-evolution]

+1 to "discardable" or "@discardable" next to the result type.

] 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.

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Oct 15, 2017, at 1:04 PM, Rudolf Adamkovič via swift-evolution 
>  wrote:
> 
> 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Rudolf Adamkovič via swift-evolution]

+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 
>  wrote:
> 
>> On 15 October 2017 at 14:23, Geordie Jay  wrote:
>> Hi Mike,
>> 
>> 2017-10-15 14:55 GMT+02:00 Mike Kluev :
 On 15 October 2017 at 13:35, Geordie Jay  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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Jean-Daniel via swift-evolution]

> Le 15 oct. 2017 à 15:52, Mike Kluev via swift-evolution 
>  a écrit :
> 
> On 15 October 2017 at 14:23, Geordie Jay  > wrote:
> Hi Mike,
> 
> 2017-10-15 14:55 GMT+02:00 Mike Kluev  >:
> On 15 October 2017 at 13:35, Geordie Jay  > 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
> 

inout and discardableResult are fundamentally different. Inout change the 
calling convention and the way the parameter is passed. discardableResult is 
just an annotation to help catching bad function usage by warning the developer 
about it.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 15 October 2017 at 14:23, Geordie Jay  wrote:

> Hi Mike,
>
> 2017-10-15 14:55 GMT+02:00 Mike Kluev :
>
>> On 15 October 2017 at 13:35, Geordie Jay  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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Geordie Jay via swift-evolution]

Hi Mike,

2017-10-15 14:55 GMT+02:00 Mike Kluev :

> On 15 October 2017 at 13:35, Geordie Jay  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).


>
> my litmus test is: "if we did it now in swift 0.0 what would we do".
> discardable before type passes this test, @discardableResult before
> function doesn't.
>

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.


>
>
>> There has been some discussion of "throws" as a keyword. If anything I
>> think that is something that is in more need of change. I've always read it
>> (frustratingly) as e.g. "func throws Bool", which it doesn't, it throws an
>> Error.
>>
>
> indeed. that's why "throws Bool" is wrong and if anything, i am advocating
> for:
>
> 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*".

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.

- Geordie
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 13 October 2017 at 22:50, Jean-Daniel  wrote:

I mean:
>
> func foo() -> Int { … }
>
> func bar(callback: () -> discardable Int) { … }
>
> bar(foo) // does it warns ?
> bar({ 3 }) // does it warns ? If it does, how to avoid it ?
>

thanks.

>>> And allowing it in signature but not in lambda would be confusing.

not any more confusing than it is now (allowing @discardableResult before
function name and not allowing it before closure parameters).

but, if to fix that, than could be this (orthogonal to whether it is
"@discardableResult" or "discardable"):

func foo() -> Int {}
func bar(_ callback: () -> discardable Int) {}

bar(foo) // error, type mismatch
bar({ 3 }) // error, type mismatch
bar({ () -> discardable Int in 3 }) // ok, types matched

- and -

func poo() -> discardable Int {}
func baz(_ callback: () -> Int) {}

baz(poo) // ok, types compatible
baz({ 3 }) // ok, types matched
baz({ () -> discardable Int in 3 }) // ok, types compatible

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Jean-Daniel via swift-evolution]

> Le 13 oct. 2017 à 23:23, Mike Kluev via swift-evolution 
>  a écrit :
> 
> On 13 October 2017 at 21:15, Jean-Daniel  > wrote:
> I don’t think this is a good idea to make discardable part of the function 
> type.
> 
> What would fun(callback: () -> discardable Int) would means ? 
> 
> you mean this?
> 
> func foo(callback: () -> discardable Int) {
> ...
> let x = callback()
> ...
> callback() // no warning or error here
> }
> 
> Mike
> 

I mean:

func foo() -> Int { … }

func bar(callback: () -> discardable Int) { … }

bar(foo) // does it warns ?
bar({ 3 }) // does it warns ? If it does, how to avoid it ?


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 13 October 2017 at 21:15, Jean-Daniel  wrote:

> I don’t think this is a good idea to make discardable part of the function
> type.
>
> What would fun(callback: () -> discardable Int) would means ?
>

you mean this?

func foo(callback: () -> discardable Int) {
...
let x = callback()
...
callback() // no warning or error here
}

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Jean-Daniel via swift-evolution]

I don’t think this is a good idea to make discardable part of the function type.

What would fun(callback: () -> discardable Int) would means ? 

And allowing it in signature but not in lambda would be confusing.


> Le 12 oct. 2017 à 15:32, Mike Kluev via swift-evolution 
>  a écrit :
> 
> On 12 October 2017 at 14:14, David James  > wrote:
> True, and it was making the method signature too long. But at least I have 
> the option to do that. If we move the annotation to just before the return 
> type, then we have no choice.
> 
> you can still put it on the next line along with the result :)
> 
> imho, this shall not be a decision maker nowadays (20 years ago it would).
> 
> 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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 12 October 2017 at 14:14, David James  wrote:

> True, and it was making the method signature too long. But at least I have
> the option to do that. If we move the annotation to just before the return
> type, then we have no choice.
>

you can still put it on the next line along with the result :)

imho, this shall not be a decision maker nowadays (20 years ago it would).

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David James via swift-evolution]

> On Oct 12, 2017, at 1:40 PM, Mike Kluev  wrote:
> 
> let me guess: you put it on a different line exactly because it is in it's 
> current ugly form :)


True, and it was making the method signature too long. But at least I have the 
option to do that. If we move the annotation to just before the return type, 
then we have no choice.

David James

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 12 October 2017 at 09:34, David James  wrote:

> IMO everyday app building would rarely need to use functions with
> discardable results. This is more an issue with libraries or frameworks
> that support a *fluent interface* (e.g. that return self) where an
> operator chain can be stopped at any point, unless it clearly doesn’t make
> sense, in which case @discardableResult would not be advised. I am building
> such a library. It has 200+ uses of @discardableResult and *I don’t have
> a problem with it in it’s current form* (especially since it can go on
> the line before the function). It’s an annotation for a specialized
> purpose, hence the very specific nomenclature.
>

let me guess: you put it on a different line exactly because it is in it's
current ugly form :)

personally, if "x: inout Int" is in it's current form (vs. "@inputOutput x:
Int") so shall be "discardable Int", i see no principle difference between
them to make one looking it is from a different planet altogether.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David James via swift-evolution]

IMO everyday app building would rarely need to use functions with discardable 
results. This is more an issue with libraries or frameworks that support a 
fluent interface (e.g. that return self) where an operator chain can be stopped 
at any point, unless it clearly doesn’t make sense, in which case 
@discardableResult would not be advised. I am building such a library. It has 
200+ uses of @discardableResult and I don’t have a problem with it in it’s 
current form (especially since it can go on the line before the function). It’s 
an annotation for a specialized purpose, hence the very specific nomenclature.

> On Oct 10, 2017, at 7:48 PM, Mike Kluev via swift-evolution 
>  wrote:
> 
> On 10 October 2017 at 07:02, Xiaodi Wu  > wrote:
> This idea was discussed long ago and the present design was selected. At this 
> point in Swift Evolution, source-breaking changes are in scope only if the 
> status quo is demonstrably harmful.
> 
> changes like discussed are not necessarily source-breaking: you can allow 
> @discardableResult for a while (along with deprecating it at some point) in 
> addition to having a newer preferred way - should we decide there is a 
> preferred way.
>  
> on Mon, 09 Oct 2017 20:07:13 +0200 Tino Heth  > wrote:
> As for the line-length, I don’t buy this argument, because placement of line 
> breaks is just personal preference, and keywords/annotations created by 
> gluing together two words should imho avoided wherever possible (not only 
> because the increased character count).
>  
> +1. same here on both counts. multi-word compound and @ symbol makes names 
> ugly. it feels it was done intentionally to indicate a "temporary" "to be 
> cleaned later" nature of a feature (it is a very good choice for @objc)
> 
> and if "fileprivate" is ugly because it is two words glued together (*) maybe 
> there is another name for it? just "file"? "domestic" ?
> 
> Mike
> (* the very concept of "file private" is a bit ugly from a traditional 
> languages perspective).
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

David James

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 10 October 2017 at 07:02, Xiaodi Wu  wrote:

> This idea was discussed long ago and the present design was selected. At
> this point in Swift Evolution, source-breaking changes are in scope only if
> the status quo is demonstrably harmful.


changes like discussed are not necessarily source-breaking: you can allow
@discardableResult for a while (along with deprecating it at some point) in
addition to having a newer preferred way - should we decide there is a
preferred way.

on Mon, 09 Oct 2017 20:07:13 +0200 Tino Heth  wrote:

> As for the line-length, I don’t buy this argument, because placement of
> line breaks is just personal preference, and keywords/annotations created
> by gluing together two words should imho avoided wherever possible (not
> only because the increased character count).


+1. same here on both counts. multi-word compound and @ symbol makes names
ugly. it feels it was done intentionally to indicate a "temporary" "to be
cleaned later" nature of a feature (it is a very good choice for @objc)

and if "fileprivate" is ugly because it is two words glued together (*)
maybe there is another name for it? just "file"? "domestic" ?

Mike
(* the very concept of "file private" is a bit ugly from a traditional
languages perspective).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Tino Heth via swift-evolution]

I don’t remember all the details, but this has been discussed when results 
became „non-discardable“ by default, and afair it was even proposed as a 
possible future improvement to make the change less ugly for those who were 
fine with the original behavior.

As for the line-length, I don’t buy this argument, because placement of line 
breaks is just personal preference, and keywords/annotations created by gluing 
together two words should imho avoided wherever possible (not only because the 
increased character count).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Xiaodi Wu via swift-evolution]

This idea was discussed long ago and the present design was selected. At
this point in Swift Evolution, source-breaking changes are in scope only if
the status quo is demonstrably harmful.
On Mon, Oct 9, 2017 at 17:16 Mike Kluev via swift-evolution <
swift-evolution@swift.org> wrote:

> On 9 October 2017 at 20:43, Howard Lovatt  wrote:
>
>>
>> I would prefer something like:
>>
>> func x() -> Bool @ throws disguardableResult public async mutating
>>
>> Where @ introduces a list of space separated modifiers.
>>
>
> make it more English :)
>
> public async mutating throwing func foo() -> discardable Bool {
> ...
> }
>
> Unfortunately I am not sure this is practical at this stage.
>>
>
> true :(
>
> 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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 9 October 2017 at 20:43, Howard Lovatt  wrote:

>
> I would prefer something like:
>
> func x() -> Bool @ throws disguardableResult public async mutating
>
> Where @ introduces a list of space separated modifiers.
>

make it more English :)

public async mutating throwing func foo() -> discardable Bool {
...
}

Unfortunately I am not sure this is practical at this stage.
>

true :(

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Howard Lovatt via swift-evolution]

Personally I would prefer all the modified to go on the right, so that the 
declaration is sorted from most important to least left to right. EG:

Instead of:

@disguardableResult public async mutating func x() throws -> Bool

I would prefer something like:

func x() -> Bool @ throws disguardableResult public async mutating

Where @ introduces a list of space separated modifiers. 

That’s why I also prefer:

   let x: Int // Swift

over:

   const int x // C

And moving the where clause to the end of the declaration. 

Unfortunately I am not sure this is practical at this stage. 

-- Howard. 

> On 10 Oct 2017, at 5:21 am, Mike Kluev via swift-evolution 
>  wrote:
> 
>> On Sat, 7 Oct 2017 07:48:08 +0100,  wrote:
>> So it would be:
>> 
>> func() -> @discardable Bool { }
>> 
>> Rather than:
>> 
>> @discardableResult func() -> Bool { }
> 
> 
> i'd say:
> 
> func foo() -> discardable Bool {
> ...
> }
> 
> if we were starting from scratch
> 
>> It could be even better if someone could perhaps find a shorter word that
>> is a synonym for the word "discardable", that would be as explicit in
>> intent as the word "discardable" is in such context, yet be written with
>> fewer characters.
> 
>  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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On Sat, 7 Oct 2017 07:48:08 +0100, 
wrote:

> So it would be:
>
> func() -> @discardable Bool { }
>
> Rather than:
>
> @discardableResult func() -> Bool { }
>


i'd say:

func foo() -> discardable Bool {
...
}

if we were starting from scratch

It could be even better if someone could perhaps find a shorter word that
> is a synonym for the word "discardable", that would be as explicit in
> intent as the word "discardable" is in such context, yet be written with
> fewer characters.
>

 Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Taylor Swift via swift-evolution]

I agree with this, function signatures in Swift are long enough as it is,
fitting them in 80 characters is hard enough already

On Mon, Oct 9, 2017 at 11:14 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> async is a keyword where as @discardableResult is an attribute. This pitch
> does not include any advantages over the current form. In fact this will
> rather harm the readbility because you no longer can nicely put the
> annotation above the function and it won’t play well with other keywords
> like throws, rethrows and async.
>
> @discardableResult
> funx foo() { /* ... */  }
>
> So -1 for this pitch.
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. Oktober 2017 um 18:02:14, Dave DeLong via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>> Oooo, I really like this.
>>
>> It also brings up an interesting point on the whole async discussion.
>> Doesn’t the async apply to the *return value* and not the other stuff?
>>
>> IE instead of:
>>
>> async func getBool() → Bool
>>
>> It could be:
>>
>> func getBool() → async Bool
>>
>> Dave
>>
>> On Oct 9, 2017, at 9:58 AM, Fil Ipe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I find it extremely cumbersome to have to precede a function declaration
>> with such an extensive annotation such as @discardableResult
>>
>> Now that so many functions do need this annotation to be there, our code
>> became so ugly.
>>
>> Besides, having this annotation precede the function declaration kind of
>> reminds me of C rather than Swift. Since in C the function declarations
>> started by the type of the return value.
>>
>> I, therefore, think it would be much softer on the eye, and much more
>> precise in intent, to instead precede the result of a func with a simpler
>> and shorter @discardable annotation
>>
>> So it would be:
>>
>> func() -> @discardable Bool { }
>>
>> Rather than:
>>
>> @discardableResult func() -> Bool { }
>>
>> It could be even better if someone could perhaps find a shorter word that
>> is a synonym for the word "discardable", that would be as explicit in
>> intent as the word "discardable" is in such context, yet be written with
>> fewer characters.
>>
>> Swift regards,
>> Filipe Sá.
>> ___
>> 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
>>
>
> ___
> 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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David Sweeris via swift-evolution]

> On Oct 9, 2017, at 9:02 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Oooo, I really like this.
> 
> It also brings up an interesting point on the whole async discussion. Doesn’t 
> the async apply to the return value and not the other stuff?

No, the whole function including any side effects gets executed asynchronously. 
"Pure" functions could (sorta) be regarded as only having the "async" apply to 
the return value, but that mental model is incorrect and it only gives the 
right "answer" as a consequence of the function being pure.

At least, if I understand things correctly.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Adrian Zubarev via swift-evolution]

async is a keyword where as @discardableResult is an attribute. This pitch does 
not include any advantages over the current form. In fact this will rather harm 
the readbility because you no longer can nicely put the annotation above the 
function and it won’t play well with other keywords like throws, rethrows and 
async.  

@discardableResult  
funx foo() { /* ... */ }

So -1 for this pitch.
--  
Adrian Zubarev
Sent with Airmail  

Am 9. Oktober 2017 um 18:02:14, Dave DeLong via swift-evolution 
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

>  
> Oooo, I really like this.  
>  
> It also brings up an interesting point on the whole async discussion. Doesn’t 
> the async apply to the return value and not the other stuff?  
>  
> IE instead of:  
>  
> async func getBool() → Bool  
>  
> It could be:  
>  
> func getBool() → async Bool  
>  
> Dave
>  
> > On Oct 9, 2017, at 9:58 AM, Fil Ipe via swift-evolution 
> >  wrote:  
> > I find it extremely cumbersome to have to precede a function declaration 
> > with such an extensive annotation such as @discardableResult
> >  
> > Now that so many functions do need this annotation to be there, our code 
> > became so ugly.  
> >  
> > Besides, having this annotation precede the function declaration kind of 
> > reminds me of C rather than Swift. Since in C the function declarations 
> > started by the type of the return value.  
> >  
> > I, therefore, think it would be much softer on the eye, and much more 
> > precise in intent, to instead precede the result of a func with a simpler 
> > and shorter @discardable annotation  
> >  
> > So it would be:  
> >  
> > func() -> @discardable Bool { }  
> >  
> > Rather than:  
> >  
> > @discardableResult func() -> Bool { }  
> >  
> > It could be even better if someone could perhaps find a shorter word that 
> > is a synonym for the word "discardable", that would be as explicit in 
> > intent as the word "discardable" is in such context, yet be written with 
> > fewer characters.  
> >  
> > Swift regards,  
> > Filipe Sá.
> >  
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto: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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Dave DeLong via swift-evolution]

Oooo, I really like this.

It also brings up an interesting point on the whole async discussion. Doesn’t 
the async apply to the return value and not the other stuff?

IE instead of:

async func getBool() → Bool

It could be:

func getBool() → async Bool

Dave

> On Oct 9, 2017, at 9:58 AM, Fil Ipe via swift-evolution 
>  wrote:
> 
> I find it extremely cumbersome to have to precede a function declaration with 
> such an extensive annotation such as @discardableResult
> 
> Now that so many functions do need this annotation to be there, our code 
> became so ugly.
> 
> Besides, having this annotation precede the function declaration kind of 
> reminds me of C rather than Swift. Since in C the function declarations 
> started by the type of the return value.
> 
> I, therefore, think it would be much softer on the eye, and much more precise 
> in intent, to instead precede the result of a func with a simpler and shorter 
> @discardable annotation
> 
> So it would be:
> 
> func() -> @discardable Bool { } 
> 
> Rather than: 
> 
> @discardableResult func() -> Bool { } 
> 
> It could be even better if someone could perhaps find a shorter word that is 
> a synonym for the word "discardable", that would be as explicit in intent as 
> the word "discardable" is in such context, yet be written with fewer 
> characters.
> 
> Swift regards,
> Filipe Sá.
> ___
> 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

[swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Fil Ipe via swift-evolution]

I find it extremely cumbersome to have to precede a function declaration
with such an extensive annotation such as @discardableResult

Now that so many functions do need this annotation to be there, our code
became so ugly.

Besides, having this annotation precede the function declaration kind of
reminds me of C rather than Swift. Since in C the function declarations
started by the type of the return value.

I, therefore, think it would be much softer on the eye, and much more
precise in intent, to instead precede the result of a func with a simpler
and shorter @discardable annotation

So it would be:

func() -> @discardable Bool { }

Rather than:

@discardableResult func() -> Bool { }

It could be even better if someone could perhaps find a shorter word that
is a synonym for the word "discardable", that would be as explicit in
intent as the word "discardable" is in such context, yet be written with
fewer characters.

Swift regards,
Filipe Sá.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution