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

> 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 e

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

> 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 > so

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

> 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

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

> 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 t

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

> 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 havin

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

> 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

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

+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. Al

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

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 >> advanta

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

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

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

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 @

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

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 @discarda

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

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

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

> 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 implem

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

> 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: discardab

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

+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

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

+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

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

> 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

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

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 someth

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

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 eith

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

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 "inou

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

Hello, While I can see the recommended change as "nice" at some level, I don't really see much practical advantage to it. The criticism of the status quo seems to be based around aesthetics. I think aesthetics of the current version are fine, given you can put the attribute on the previous line, l

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

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 woul

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

> 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) w

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

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()

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

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 O

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

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

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

> 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 th

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

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

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

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 ca

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

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-brea

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

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 th

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

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 Octobe

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

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() -> disca

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

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 disgua

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

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 f

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

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.

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

> 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 effe

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

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 th

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

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

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

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 r