/*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
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á.

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

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

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

···

On Oct 9, 2017, at 9:02 AM, Dave DeLong via swift-evolution <swift-evolution@swift.org> 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?

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 <swift-evolution@swift.org(mailto: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(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

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