Sorry, I'm sure this has been discussed before, but what the heck???
This feature is killing me. Now I have go add @discardableResult to every
function that returns a non-Void or use the ugly syntax `_ =`?
Until swift 3 I've really enjoyed the new language. Now I find it to be
getting too rigid for the sake of "protecting" me from myself. The safety
levels needs to be dialled back some.
Functions that return values return them for a reason. Ignoring them is, more likely than not, an oversight that should be corrected, hence @discardableResult. We're talking error codes, object lifetime tokens, failure indicators, etc. All things that result in ignoring critical code paths for the sake of convenience. If you find yourself executing a lot of side effects and ignoring return values, I would take a look at why. A lot of times you have control over the API and can eliminate some of these unused return values. Otherwise, please try to see if the return values of these functions are relevant to the well-being of your program.
~Robert Widmann
2016/10/30 8:49、Jody Schofield via swift-dev <swift-dev@swift.org> のメッセージ:
Sorry, I'm sure this has been discussed before, but what the heck???
This feature is killing me. Now I have go add @discardableResult to every function that returns a non-Void or use the ugly syntax `_ =`?
Until swift 3 I've really enjoyed the new language. Now I find it to be getting too rigid for the sake of "protecting" me from myself. The safety levels needs to be dialled back some.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
I think we're generally very comfortable with this rule; forgetting to handle a return value (maybe because you expect the function to be mutating) is a pretty common mistake, and "_ = " seems nicer than the old C equivalent "(void)".
Do you find yourself writing a lot of functions that return non-void results that you frequently want to ignore? Maybe there's some idiom we could do a better job of recognizing.
John.
On Oct 30, 2016, at 5:49 AM, Jody Schofield via swift-dev <swift-dev@swift.org> wrote:
Sorry, I'm sure this has been discussed before, but what the heck???This feature is killing me. Now I have go add @discardableResult to every function that returns a non-Void or use the ugly syntax `_ =`?
Until swift 3 I've really enjoyed the new language. Now I find it to be getting too rigid for the sake of "protecting" me from myself. The safety levels needs to be dialled back some.
I think assumptions are being made that shouldn't be. For example I use a lot for design patterns such as the builder. Most of the methods return a reference to self so they can be chained together. The compiler shouldn't tell me I'm wrong for ignoring those return values. It use to be my decision.
Swift was already a very opinionated language and I can see it's being taken even further. A mistake in my opinion and one that is certainly making the language more frustrating than pleasurable to use.
On Oct 30, 2016, at 1:32 PM, Robert Widmann <devteam.codafi@gmail.com> wrote:
Functions that return values return them for a reason. Ignoring them is, more likely than not, an oversight that should be corrected, hence @discardableResult. We're talking error codes, object lifetime tokens, failure indicators, etc. All things that result in ignoring critical code paths for the sake of convenience. If you find yourself executing a lot of side effects and ignoring return values, I would take a look at why. A lot of times you have control over the API and can eliminate some of these unused return values. Otherwise, please try to see if the return values of these functions are relevant to the well-being of your program.
~Robert Widmann
2016/10/30 8:49、Jody Schofield via swift-dev <swift-dev@swift.org> のメッセージ:
Sorry, I'm sure this has been discussed before, but what the heck???
This feature is killing me. Now I have go add @discardableResult to every function that returns a non-Void or use the ugly syntax `_ =`?
Until swift 3 I've really enjoyed the new language. Now I find it to be getting too rigid for the sake of "protecting" me from myself. The safety levels needs to be dialled back some.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
I agree that "_ =" is nicer than "(void)".
Do you find yourself writing a lot of functions that return non-void
results that you frequently want to ignore? Maybe there's some idiom we
could do a better job of recognizing.
It really depends on the developer. Some will add return values thinking
it's important to and others don't. It certainly is obvious around our use
of the builders and in our unit tests. I'll go back and review the unit
tests, but I think there are enough valid cases where we don't care about
return values if we are spying, mocking, etc.
On Mon, Oct 31, 2016 at 7:14 PM, John McCall <rjmccall@apple.com> wrote:
On Oct 30, 2016, at 5:49 AM, Jody Schofield via swift-dev < > swift-dev@swift.org> wrote:
Sorry, I'm sure this has been discussed before, but what the heck???This feature is killing me. Now I have go add @discardableResult to every
function that returns a non-Void or use the ugly syntax `_ =`?Until swift 3 I've really enjoyed the new language. Now I find it to be
getting too rigid for the sake of "protecting" me from myself. The safety
levels needs to be dialled back some.I think we're generally very comfortable with this rule; forgetting to
handle a return value (maybe because you expect the function to be
mutating) is a pretty common mistake, and "_ = " seems nicer than the old C
equivalent "(void)".Do you find yourself writing a lot of functions that return non-void
results that you frequently want to ignore? Maybe there's some idiom we
could do a better job of recognizing.John.
If the methods return a reference to self it indicates that you should probably just chain expressions together rather than using a big wall of statements (Smalltalk encourages the same pattern, funnily enough).
As for the rest, yeah Swift is opinionated. Every language is opinionated. We just happen to care about being safe by default.
~Robert Widmann
2016/10/30 13:52、Jody Schofield <jodyscho@gmail.com> のメッセージ:
I think assumptions are being made that shouldn't be. For example I use a lot for design patterns such as the builder. Most of the methods return a reference to self so they can be chained together. The compiler shouldn't tell me I'm wrong for ignoring those return values. It use to be my decision.
Swift was already a very opinionated language and I can see it's being taken even further. A mistake in my opinion and one that is certainly making the language more frustrating than pleasurable to use.
On Oct 30, 2016, at 1:32 PM, Robert Widmann <devteam.codafi@gmail.com> wrote:
Functions that return values return them for a reason. Ignoring them is, more likely than not, an oversight that should be corrected, hence @discardableResult. We're talking error codes, object lifetime tokens, failure indicators, etc. All things that result in ignoring critical code paths for the sake of convenience. If you find yourself executing a lot of side effects and ignoring return values, I would take a look at why. A lot of times you have control over the API and can eliminate some of these unused return values. Otherwise, please try to see if the return values of these functions are relevant to the well-being of your program.
~Robert Widmann
2016/10/30 8:49、Jody Schofield via swift-dev <swift-dev@swift.org> のメッセージ:
Sorry, I'm sure this has been discussed before, but what the heck???
This feature is killing me. Now I have go add @discardableResult to every function that returns a non-Void or use the ugly syntax `_ =`?
Until swift 3 I've really enjoyed the new language. Now I find it to be getting too rigid for the sake of "protecting" me from myself. The safety levels needs to be dialled back some.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
If you're engaging in a non-standard design pattern, that you are
willfully writing yourself, I really don't see what the problem is with
applying @discardableResult to declarations that need it, just like any
of Swift's other decorators that describe convention and use patterns.
Cheers,
Zach
On Sun, Oct 30, 2016, at 01:52 PM, Jody Schofield via swift-evolution wrote:
I think assumptions are being made that shouldn't be. For example I
use a lot for design patterns such as the builder. Most of the methods
return a reference to self so they can be chained together. The
compiler shouldn't tell me I'm wrong for ignoring those return values.
It use to be my decision.
Swift was already a very opinionated language and I can see it's being
taken even further. A mistake in my opinion and one that is certainly
making the language more frustrating than pleasurable to use.On Oct 30, 2016, at 1:32 PM, Robert Widmann > <devteam.codafi@gmail.com> wrote:
Functions that return values return them for a reason. Ignoring them
is, more likely than not, an oversight that should be corrected,
hence @discardableResult. We're talking error codes, object lifetime
tokens, failure indicators, etc. All things that result in ignoring
critical code paths for the sake of convenience. If you find
yourself executing a lot of side effects and ignoring return values,
I would take a look at why. A lot of times you have control over the
API and can eliminate some of these unused return values. Otherwise,
please try to see if the return values of these functions are
relevant to the well-being of your program.~Robert Widmann
2016/10/30 8:49、Jody Schofield via swift-dev <swift-dev@swift.org>
のメッセージ:Sorry, I'm sure this has been discussed before, but what the heck???
This feature is killing me. Now I have go add @discardableResult to
every function that returns a non-Void or use the ugly syntax `_ =`?Until swift 3 I've really enjoyed the new language. Now I find it to
be getting too rigid for the sake of "protecting" me from myself.
The safety levels needs to be dialled back some._______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev_________________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Actually this particular feature prevents you from doing anything reckless, like ignoring a method that would return a different instance of the self for example. By enforcing the default, anyone using the builder will effectively chain the calls and set the result only once OR write over the result over and over on consecutive lines as there is no was to know if you actually return the self or a new instance inside that builder. That pattern is effectively recommended when you pay attention to immutability/value types, where every single mutation the builder is exercising on 'self' could/should produce a different instance.
--
Florent Vilmart
Le 30 octobre 2016 à 14:09:40, Robert Widmann via swift-evolution (swift-evolution@swift.org) a écrit:
If the methods return a reference to self it indicates that you should probably just chain expressions together rather than using a big wall of statements (Smalltalk encourages the same pattern, funnily enough).
As for the rest, yeah Swift is opinionated. Every language is opinionated. We just happen to care about being safe by default.
~Robert Widmann
2016/10/30 13:52、Jody Schofield <jodyscho@gmail.com> のメッセージ:
I think assumptions are being made that shouldn't be. For example I use a lot for design patterns such as the builder. Most of the methods return a reference to self so they can be chained together. The compiler shouldn't tell me I'm wrong for ignoring those return values. It use to be my decision.
Swift was already a very opinionated language and I can see it's being taken even further. A mistake in my opinion and one that is certainly making the language more frustrating than pleasurable to use.
On Oct 30, 2016, at 1:32 PM, Robert Widmann <devteam.codafi@gmail.com> wrote:
Functions that return values return them for a reason. Ignoring them is, more likely than not, an oversight that should be corrected, hence @discardableResult. We're talking error codes, object lifetime tokens, failure indicators, etc. All things that result in ignoring critical code paths for the sake of convenience. If you find yourself executing a lot of side effects and ignoring return values, I would take a look at why. A lot of times you have control over the API and can eliminate some of these unused return values. Otherwise, please try to see if the return values of these functions are relevant to the well-being of your program.
~Robert Widmann
2016/10/30 8:49、Jody Schofield via swift-dev <swift-dev@swift.org> のメッセージ:
Sorry, I'm sure this has been discussed before, but what the heck???
This feature is killing me. Now I have go add @discardableResult to every function that returns a non-Void or use the ugly syntax `_ =`?
Until swift 3 I've really enjoyed the new language. Now I find it to be getting too rigid for the sake of "protecting" me from myself. The safety levels needs to be dialled back some.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
If the methods return a reference to self it indicates that you should probably just chain expressions together rather than using a big wall of statements (Smalltalk encourages the same pattern, funnily enough).
Smalltalk specifically has builtin syntax for method cascades, which seem to me like a nicer language-level solution to chaining method calls without requiring them to be manually defined in a "builder pattern" style.
-Joe
On Oct 30, 2016, at 11:09 AM, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:
As for the rest, yeah Swift is opinionated. Every language is opinionated. We just happen to care about being safe by default.
~Robert Widmann
2016/10/30 13:52、Jody Schofield <jodyscho@gmail.com> のメッセージ:
I think assumptions are being made that shouldn't be. For example I use a lot for design patterns such as the builder. Most of the methods return a reference to self so they can be chained together. The compiler shouldn't tell me I'm wrong for ignoring those return values. It use to be my decision.
Swift was already a very opinionated language and I can see it's being taken even further. A mistake in my opinion and one that is certainly making the language more frustrating than pleasurable to use.
On Oct 30, 2016, at 1:32 PM, Robert Widmann <devteam.codafi@gmail.com> wrote:
Functions that return values return them for a reason. Ignoring them is, more likely than not, an oversight that should be corrected, hence @discardableResult. We're talking error codes, object lifetime tokens, failure indicators, etc. All things that result in ignoring critical code paths for the sake of convenience. If you find yourself executing a lot of side effects and ignoring return values, I would take a look at why. A lot of times you have control over the API and can eliminate some of these unused return values. Otherwise, please try to see if the return values of these functions are relevant to the well-being of your program.
~Robert Widmann
2016/10/30 8:49、Jody Schofield via swift-dev <swift-dev@swift.org> のメッセージ:
Sorry, I'm sure this has been discussed before, but what the heck???
This feature is killing me. Now I have go add @discardableResult to every function that returns a non-Void or use the ugly syntax `_ =`?
Until swift 3 I've really enjoyed the new language. Now I find it to be getting too rigid for the sake of "protecting" me from myself. The safety levels needs to be dialled back some.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I hope we'll see method chaining in 4 phase 2
-- E
On Oct 31, 2016, at 12:14 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 30, 2016, at 11:09 AM, Robert Widmann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
If the methods return a reference to self it indicates that you should probably just chain expressions together rather than using a big wall of statements (Smalltalk encourages the same pattern, funnily enough).
Smalltalk specifically has builtin syntax for method cascades, which seem to me like a nicer language-level solution to chaining method calls without requiring them to be manually defined in a "builder pattern" style.
-Joe