[swift-evolution] [swift-dev] SE-0047 - Defaulting non-Void functions so they warn on unused results

[Florent Vilmart]

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 at 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 at 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 at 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 at 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 at swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161030/e56b2860/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 101 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161030/e56b2860/attachment.sig>