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

• What is your evaluation of the proposal? Great idea • Is the problem being addressed significant enough to warrant a change to Swift? Yes I think so, currently the declaration line is very cluttered with lots of noise up front that hides what the line actually does. This proposal removes

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

> On Mar 27, 2016, at 6:33 AM, Maximilian Hünenberger via swift-evolution > wrote: > > In the proposal there is no mention of generic functions. > Take a map function of a Wrapper: > > Wrapper { >func map(transform: T -> U) -> U { ... } > } > > let

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

on Thu Mar 24 2016, Andrey Tarantsov wrote: >>> The new default is better for: >>> >>> - (A) classes that provide both mutating and non-mutating methods; >>> - (B) methods where forgetting to use the result produces a bug (a >>> download task that needs to be

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

>> The new default is better for: >> >> - (A) classes that provide both mutating and non-mutating methods; >> - (B) methods where forgetting to use the result produces a bug (a >> download task that needs to be resumed, an alert that needs to be >> displayed, a listener that needs to be stored

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

> What is your evaluation of the proposal? -0.5 if the annotation is verbose (much longer than @discardable). +0.5 if the annotation is pleasant and concise, like @discardable > Is the problem being addressed significant enough to warrant a change to > Swift? The warn-by-default behavior is

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

> On 21 Mar 2016, at 23:21, Adrian Kashivskyy wrote: > > I believe the scoped @discardableResult(warn|critical) attribute is a nice > idea for future directions, but I'm not sure it's in scope of this proposal, > which, as a first small step, aims to basically

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

I believe the scoped @discardableResult(warn|critical) attribute is a nice idea for future directions, but I'm not sure it's in scope of this proposal, which, as a first small step, aims to basically invert the @warn_unused_result standard. cc Erica Pozdrawiam – Regards, Adrian Kashivskyy >

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

> On 21 Mar 2016, at 20:35, Erica Sadun via swift-evolution > wrote: > In Swift Evolution discussions, the term @discardable was mildly preferred > over @discardableResult. > > Some community members requested a new attribute enabling exceptional > imported

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

> On Mar 16, 2016, at 11:46 PM, Adrian Kashivskyy via swift-evolution > wrote: > > @Jed, > >> That said, the problem isn’t necessarily difficult to solve — it’s just that >> it’s important that it actually be solved at the same time the feature is >> rolled out. >

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

Strong +1, with some nitpicks to enclosed example: I disagree that NSNotificationCenter’s returned token should be ignored without warning—this goes against the patterns I’ve seen in programming Cocoa the last 27 years, where needing to unregistering for notifications when an object is

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

>> I also don't like that this proposal doesn't include an "Impact on existing >> code" section. We ought to decide whether the migrator will add >> `@discardableResult` to existing symbols or not. > > I totally agree with Erica – the migrator should only remove existing > @warn_unused_result

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

> The review of “Defaulting non-Void functions so they warn on unused results” > begins now and runs through March 21, 2016. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md > > • What is your evaluation of

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

+1 but: I'm somewhat hesistant about not marking the plausibly discarable ones @discardableResult. - I rarely use the result value of removeLast() and I don't see how requiring it here adds any safety. It is obvious this call has side-effects and doesn't just return the last element. - I would

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

Hello Swift community, The review of “Defaulting non-Void functions so they warn on unused results” begins now and runs through March 21, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md Reviews are an important

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

> On Mar 17, 2016, at 1:09 PM, Dan Raviv via swift-evolution > wrote: > > -1 for > this behavior in playgrounds. I've been told that this is automatically disabled in playgrounds (waves hi to Jordan R) since results are always used by displaying them in the

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

@Patrick, > I rarely use the result value of removeLast() and I don't see how requiring > it here adds any safety. It is obvious this call has side-effects and doesn't > just return the last element. Actually, removeLast() and other pop()-like functions are examples of functions that will

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

In theory, I like this idea, and I think it fits with the general direction of Swift in terms of making APIs and their usage more explicit, particularly custom and third-party ones, but I’m concerned about what would happen if system APIs that were intended to have discardable results aren’t

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

> Le 16 mars 2016 à 15:36, Chris Lattner via swift-evolution > a écrit : > > Hello Swift community, > > The review of “Defaulting non-Void functions so they warn on unused results” > begins now and runs through March 21, 2016. The proposal is available here: > >

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

> • What is your evaluation of the proposal? -1 This clearly makes me part of a small minority, but I doubt that the participants of this discussion are representative for all current and future users of Swift: Those who enjoy tinkering with the design of languages naturally strive for a

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

*What is your evaluation of the proposal?* +1 *Is the problem being addressed significant enough to warrant a change to Swift?* Yes, the current annotation is present on most non-void functions, it adds a large number of lines to files that are properly annotated. *Does this proposal fit well