Also this is not without precedent and feels more swift like to me. In switch cases you can include or drop the let or the var.
for example;
switch coord {
case (let x, _): print(x)
case (_, let y); print(y)
case let (x, y): print(x,y)
}
underscore does not need the keyword let here.
···
On Feb 24, 2016, at 9:59 PM, Paul Ossenbruggen <possen@gmail.com> wrote:
Since we don’t care about the result?
_ = ignoreResult()
It does not matter whether it is mutable or not so dropping the keyword is ok here. This is really obvious what it does and is concise.
On Feb 24, 2016, at 9:54 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:
On Feb 24, 2016, at 9:19 PM, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:
These lack conciseness. What about the already supported:
let _ = ingoreResult()
I would be perfectly happy with requiring “let _ = “ myself. My recollection of the previous discussion is that most people didn’t want that to be necessary and preferred a suppressible warning.
Thinking about the attribute name some more, I might prefer:
@NoUnusedResultWarning
which is a variation of one of Erica’s suggestions. It is at least slightly shorter than @SuppressUnusedResultWarning
—CK
Where ignoreResult is the function. Or maybe something even more brief? What was wrong with (void)? or
(_)ingoreResult()
- Paul
On Feb 24, 2016, at 8:42 PM, Charles Kissinger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 24, 2016, at 7:12 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'd rather have something clear than short.
Some short ones that haven't been mentioned: @Statement has a problem because the result can be used, it's just not mandated. @Statementable just makes no English sense at all (similarly @Procedurable) but kind of communicates the idea @ResultDiscardable: not a fan @StatementAllowed or @AllowStatement really doesn't make a ton of sense, but it's short and kind of gets the point across. @SideEffects also short, also kind hints at stuff, also could be misleading, and the same for @HasSideEffects.
My favorite remains @SuppressUnusedResultWarning, which isn't short but pretty damn clear.
+1. This would be my choice as well. It is the warning that is affected, not the result, so “Warning” or “NoWarn” should be in the name.
—CK
On Feb 24, 2016, at 7:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
@optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
I stumbled across @warn_unused_result pretty early on when learning Swift, but I still miss it on around 90% of my method declarations that should have it, particularly if I’m filling something out quickly to flesh it out later. I think in part of the problem is simply that it’s extra detail to add, which is kind of strange in Swift when we have all our time savers like type inference and the simplified forms of closures; it makes more sense to add an attribute in the less common case, which in my experience is having a method result that may not be needed.
I’d liken it to mutable variables that you don’t actually mutate; it’s an error I run into all the time, but I’d rather have false positives then miss cases. It’s also important on structs with both mutating and non-mutating options; while the choice of let or var should keep you right much of the time, sometimes you do want a copy from a mutable value, so a mistakenly typing .reverse() instead of .reversed() for example is a mistake that result usage warnings can help prevent, but as long as developers keep forgetting to add @warn_unused_result it’s a warning that may not come up when it’s really needed =)
···
On 24 Feb 2016, at 23:45, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Ideally every function would be perfectly annotated but ultimately not every API developer will know about, remember or put in the effort to annotate with @warn_unused_result. Making the inverse the default should hopefully be “safer” by warning by default.
While I like the brevity, I don’t think @ignoreresult is clear enough on what it does, @optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form. Or there’s Sean’s @discardable_result alternative which is even clearer.
Otherwise @allow_unused_result is the best of the three word options I think; @suppress_unused_result is a bit unclear as what you’re actually suppressing is the compiler warning, as in most cases a result will still be generated, it’s just not stored anywhere at the call site.
···
On 24 Feb 2016, at 23:44, Janosch Hildebrand <jnosh@jnosh.com> wrote:
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
Also the aforementioned “Modernizing Attribute Case and Attribute Argument Naming” proposal[1] will also play into this discussion as well.
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
@no_warn_unused_result would seem to be the least confusable spelling. @incidental_result would be semantically valid and shorter, but I can't
say I like it.
···
on Wed Feb 24 2016, Janosch Hildebrand <jnosh-AT-jnosh.com> wrote:
Also the aforementioned “Modernizing Attribute Case and Attribute
Argument Naming” proposal[1] will also play into this discussion as
well.
On 24 Feb 2016, at 21:37, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 24 Feb 2016, at 19:27, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Feb 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute
Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is
working on a proposal already I would offer myself up for writing
this up.
I don’t recall a real proposal, it would be great for you to drive this.
Yes, please! I *really* want this change.
Same!
The only thing that needs to be considered is what to name the
replacement attribute (for methods where the return value isn’t
important). I’m thinking @optionalReturn or @ignoreUnusedResult or
such.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution
@discardable_result is nice. I kinda wish it were an annotation on the result
type; then it could just be @discardable.
···
on Wed Feb 24 2016, Haravikk <swift-evolution-AT-haravikk.me> wrote:
On 24 Feb 2016, at 23:44, Janosch Hildebrand <jnosh@jnosh.com> wrote:
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
Also the aforementioned “Modernizing Attribute Case and Attribute
Argument Naming” proposal[1] will also play into this discussion as
well.
While I like the brevity, I don’t think @ignoreresult is clear enough
on what it does, @optional_result (or ideally @optionalResult if
camel-case for attributes is accepted) is clearer I think if we want a
shortened two-word form. Or there’s Sean’s @discardable_result
alternative which is even clearer.
Otherwise @allow_unused_result is the best of the three word options I
think; @suppress_unused_result is a bit unclear as what you’re
actually suppressing is the compiler warning, as in most cases a
result will still be generated, it’s just not stored anywhere at the
call site.
This could work until we gain some other, general purpose, method to suppress warnings, though it isn’t pretty IMO. For example, if a class’ methods are designed to be chain able then the result isn’t necessary (it’s just self), so in things like loops you could end up having to use let _ an awful lot, like so:
class Chainable {
var value = 0
func add(add:Int) {
value += add
return self
}
}
let chainable = Chainable()
for _ in 0 ..< 10 {
if getSomeCondition() {
let _ = chainable.add(5)
} else {
let _ = chainable.add(2)
}
}
Stupid example, but imagine if there were a few other operations, perhaps handled by other conditionals, then suddenly you end up with a lot of these let _ statements, which is why being able to suppress the warnings in all cases is still desirable.
On the topic of verbosity in the attribute, I don’t think there’s any need to go to four words; the current attribute is @warn_unused_result, and I think that @ignore_unused_result works a direct opposite (i.e- the result being unused is still strange to the compiler, but it chooses not to issue a warning about it). I’m only using snake case because that’s what the current value has, obviously we’ll adjust for whatever the final attribute naming convention turns out to be.
···
On 25 Feb 2016, at 05:19, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:
These lack conciseness. What about the already supported:
I'd recommend against snake case. (It's a thing). Some thoughts:
Whatever we do for this particular attribute will not be different than
what we do for other similar attributes. If we decide to move all
attributes away from snake case, we'll make a unified policy decision.
Please let's not confuse the issue by introducing a new axis of
variability for this particular proposal.
···
on Wed Feb 24 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Feb 24, 2016, at 5:08 PM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 24 Feb 2016, at 23:44, Janosch Hildebrand <jnosh@jnosh.com <mailto:jnosh@jnosh.com>> wrote:
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
Also the aforementioned “Modernizing Attribute Case and Attribute
Argument Naming” proposal[1] will also play into this discussion as
well.
While I like the brevity, I don’t think @ignoreresult is clear
enough on what it does, @optional_result (or ideally @optionalResult
if camel-case for attributes is accepted) is clearer I think if we
want a shortened two-word form. Or there’s Sean’s @discardable_result alternative which is even clearer.
Otherwise @allow_unused_result is the best of the three word options
I think; @suppress_unused_result is a bit unclear as what you’re
actually suppressing is the compiler warning, as in most cases a
result will still be generated, it’s just not stored anywhere at the
call site.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution
I’m on board with @AllowUnusedResult or @IgnoreUnusedResult.
I think allow looks nicer and works as an attribute, but I suspect though that this may have an implied suggestion that without it, this is disallowed (rather than just a warning).
···
On 25 Feb 2016, at 11:22 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
I'd recommend against snake case. (It's a thing). Some thoughts:
On Feb 24, 2016, at 5:08 PM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 24 Feb 2016, at 23:44, Janosch Hildebrand <jnosh@jnosh.com <mailto:jnosh@jnosh.com>> wrote:
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
Also the aforementioned “Modernizing Attribute Case and Attribute Argument Naming” proposal[1] will also play into this discussion as well.
Without the “let” is not objectionable, using your example:
let chainable = Chainable()
for _ in 0 ..< 10 {
if getSomeCondition() {
_ = chainable.add(5)
} else {
_ = chainable.add(2)
}
}
Let is unnecessary since we are just throwing away the result we don’t need the keyword. It is optional. I don’t think @ignoreUnusedResult or the other options looks very nice either.
···
On Feb 24, 2016, at 11:50 PM, Haravikk <swift-evolution@haravikk.me> wrote:
On 25 Feb 2016, at 05:19, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
These lack conciseness. What about the already supported:
let _ = ingoreResult()
This could work until we gain some other, general purpose, method to suppress warnings, though it isn’t pretty IMO. For example, if a class’ methods are designed to be chain able then the result isn’t necessary (it’s just self), so in things like loops you could end up having to use let _ an awful lot, like so:
class Chainable {
var value = 0
func add(add:Int) {
value += add
return self
}
}
let chainable = Chainable()
for _ in 0 ..< 10 {
if getSomeCondition() {
let _ = chainable.add(5)
} else {
let _ = chainable.add(2)
}
}
Stupid example, but imagine if there were a few other operations, perhaps handled by other conditionals, then suddenly you end up with a lot of these let _ statements, which is why being able to suppress the warnings in all cases is still desirable.
On the topic of verbosity in the attribute, I don’t think there’s any need to go to four words; the current attribute is @warn_unused_result, and I think that @ignore_unused_result works a direct opposite (i.e- the result being unused is still strange to the compiler, but it chooses not to issue a warning about it). I’m only using snake case because that’s what the current value has, obviously we’ll adjust for whatever the final attribute naming convention turns out to be.
These lack conciseness. What about the already supported:
let _ = ingoreResult()
This could work until we gain some other, general purpose, method to suppress warnings, though it isn’t pretty IMO. For example, if a class’ methods are designed to be chain able then the result isn’t necessary (it’s just self), so in things like loops you could end up having to use let _ an awful lot, like so:
class Chainable {
var value = 0
func add(add:Int) {
value += add
return self
}
}
let chainable = Chainable()
for _ in 0 ..< 10 {
if getSomeCondition() {
let _ = chainable.add(5)
} else {
let _ = chainable.add(2)
}
}
Stupid example, but imagine if there were a few other operations, perhaps handled by other conditionals, then suddenly you end up with a lot of these let _ statements, which is why being able to suppress the warnings in all cases is still desirable.
You convince me here. The two ways to ensure we do this deliberately seem useful and not conflicting.
On the topic of verbosity in the attribute, I don’t think there’s any need to go to four words; the current attribute is @warn_unused_result, and I think that @ignore_unused_result works a direct opposite (i.e- the result being unused is still strange to the compiler, but it chooses not to issue a warning about it). I’m only using snake case because that’s what the current value has, obviously we’ll adjust for whatever the final attribute naming convention turns out to be.
+1 Coherent, expressive and short!
Mathieu
···
Le 25 févr. 2016 à 08:50, Haravikk via swift-evolution <swift-evolution@swift.org> a écrit :
On 25 Feb 2016, at 05:19, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:
I agree that the attribute should be attached to the return type instead that to the function.
I’d say that the cases where it’s ok to discard the result are when the result is not strictly part of the API, but provided because it could be useful to the caller. An attribute that would naturally describe this could be
@convenience
The first example that comes to mind is Dictionary.updateValue. The declaration could then become
> @optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
I don't like "optional" here because it falsely implies a connection with the Optional type.
I do think, however, that this needs to be something very short—one or two words, not three or four. One way to trim words would be to attach the attribute to the return type; the position would imply that the keyword related to the return type, so the word "result" would be unnecessary:
@ignoreUnusedResult mutating func removeLast() ->Element
mutating func removeLast() ->@ignoreUnused Element
That might be a little strange, though—we don't currently have any attributes in that position.
Another way to make this shorter is to try to find an adjective which implies *why* we can ignore the result—that is, because it isn't important. The problem is that most such adjectives are either compound words:
@unimportantResult mutating func removeLast() ->Element
mutating func removeLast() ->@unimportant Element
@discardableResult mutating func removeLast() ->Element
mutating func removeLast() ->@discardable Element
Or they're uncommon words people may need to look up:
@banalResult mutating func removeLast() ->Element
mutating func removeLast() ->@banal Element
Actually, I can think of one word in the latter category that many programmers *do* know:
@trivialResult mutating func removeLast() ->Element
mutating func removeLast() ->@trivial Element
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
@no_warn_unused_result would seem to be the least confusable spelling. @incidental_result would be semantically valid and shorter, but I can't
say I like it.
Also the aforementioned “Modernizing Attribute Case and Attribute
Argument Naming” proposal[1] will also play into this discussion as
well.
On 24 Feb 2016, at 21:37, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 24 Feb 2016, at 19:27, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Feb 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute
Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is
working on a proposal already I would offer myself up for writing
this up.
I don’t recall a real proposal, it would be great for you to drive this.
Yes, please! I *really* want this change.
Same!
The only thing that needs to be considered is what to name the
replacement attribute (for methods where the return value isn’t
important). I’m thinking @optionalReturn or @ignoreUnusedResult or
such.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> https://lists.swift.org/mailman/listinfo/swift-evolution<https://lists.swift.org/mailman/listinfo/swift-evolution>
While I like the brevity, I don’t think @ignoreresult is clear enough
on what it does, @optional_result (or ideally @optionalResult if
camel-case for attributes is accepted) is clearer I think if we want a
shortened two-word form. Or there’s Sean’s @discardable_result
alternative which is even clearer.
Otherwise @allow_unused_result is the best of the three word options I
think; @suppress_unused_result is a bit unclear as what you’re
actually suppressing is the compiler warning, as in most cases a
result will still be generated, it’s just not stored anywhere at the
call site.
@discardable_result is nice. I kinda wish it were an annotation on the result
type; then it could just be @discardable.
On 24 Feb 2016, at 23:44, Janosch Hildebrand <jnosh@jnosh.com> wrote:
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
Also the aforementioned “Modernizing Attribute Case and Attribute
Argument Naming” proposal[1] will also play into this discussion as
well.
While I like the brevity, I don’t think @ignoreresult is clear enough
on what it does, @optional_result (or ideally @optionalResult if
camel-case for attributes is accepted) is clearer I think if we want a
shortened two-word form. Or there’s Sean’s @discardable_result
alternative which is even clearer.
Otherwise @allow_unused_result is the best of the three word options I
think; @suppress_unused_result is a bit unclear as what you’re
actually suppressing is the compiler warning, as in most cases a
result will still be generated, it’s just not stored anywhere at the
call site.
@discardable_result is nice. I kinda wish it were an annotation on the result
type; then it could just be @discardable.
Whoa. Everyone seems to be in favor of this. Don't you guys always
return something ‘just in case’, in the best traditions of C API design?
I tend to have lots of discardable results and only a few where I might
legitimately forget to use it.
IMO, in most cases ignoring a return value is “safe”:
a) If a method is called only for its result, forgetting to use the
result won't really introduce any new bugs — if you're not using that
missing result elsewhere, storing it into a variable won't help.
b) If you're calling a method for its side effect, normally the result
may be discarded.
The only case where this matters is when the method establishes a long-
term relationship (like a subscription) that needs to be stored to
survive. That seems like a rare case.
On Feb 25, 2016, at 1:13 AM, Nicola Salmoria via swift-evolution <swift-evolution@swift.org> wrote:
I agree that the attribute should be attached to the return type instead that to the function.
I’d say that the cases where it’s ok to discard the result are when the result is not strictly part of the API, but provided because it could be useful to the caller. An attribute that would naturally describe this could be
@convenience
The first example that comes to mind is Dictionary.updateValue. The declaration could then become
On 25 Feb 2016, at 09:13, Nicola Salmoria via swift-evolution <swift-evolution@swift.org> wrote:
I agree that the attribute should be attached to the return type instead that to the function.
I’d say that the cases where it’s ok to discard the result are when the result is not strictly part of the API, but provided because it could be useful to the caller. An attribute that would naturally describe this could be
@convenience
The first example that comes to mind is Dictionary.updateValue. The declaration could then become
> > @optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
> I don't like "optional" here because it falsely implies a connection with the Optional type.
>
> I do think, however, that this needs to be something very short—one or two words, not three or four. One way to trim words would be to attach the attribute to the return type; the position would imply that the keyword related to the return type, so the word "result" would be unnecessary:
>
> @ignoreUnusedResult mutating func removeLast() ->Element
> mutating func removeLast() ->@ignoreUnused Element
>
> That might be a little strange, though—we don't currently have any attributes in that position.
>
> Another way to make this shorter is to try to find an adjective which implies *why* we can ignore the result—that is, because it isn't important. The problem is that most such adjectives are either compound words:
>
> @unimportantResult mutating func removeLast() ->Element
> mutating func removeLast() ->@unimportant Element
>
> @discardableResult mutating func removeLast() ->Element
> mutating func removeLast() ->@discardable Element
>
> Or they're uncommon words people may need to look up:
>
> @banalResult mutating func removeLast() ->Element
> mutating func removeLast() ->@banal Element
>
> Actually, I can think of one word in the latter category that many programmers *do* know:
>
> @trivialResult mutating func removeLast() ->Element
> mutating func removeLast() ->@trivial Element
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I’d say that the cases where it’s ok to discard the result are when the result is not strictly part of the API, but provided because it could be useful to the caller. An attribute that would naturally describe this could be
@convenience
The first example that comes to mind is Dictionary.updateValue. The declaration could then become
Thanks for the encouragement everyone! I’ll start drafting over the
weekend.
With regard to the inverted attribute, that is definitely open to
discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy @allow_unused_result - suggested by Kevin Ballard @ignoreresult - suggested by Brent Royal-Gordon
@no_warn_unused_result would seem to be the least confusable spelling. @incidental_result would be semantically valid and shorter, but I can't
say I like it.
Also the aforementioned “Modernizing Attribute Case and Attribute
Argument Naming” proposal[1] will also play into this discussion as
well.
On 24 Feb 2016, at 21:37, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:
On 24 Feb 2016, at 19:27, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
on Wed Feb 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution < > swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute
Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is
working on a proposal already I would offer myself up for writing
this up.
I don’t recall a real proposal, it would be great for you to drive this.
Yes, please! I *really* want this change.
Same!
The only thing that needs to be considered is what to name the
replacement attribute (for methods where the return value isn’t
important). I’m thinking @optionalReturn or @ignoreUnusedResult or
such.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org
<swift-evolution@swift.org>> https://lists.swift.org/mailman/listinfo/swift-evolution< https://lists.swift.org/mailman/listinfo/swift-evolution>
The reason for warning on ignored "safe" returned values is that the
code calls the method, but it ignores the result. Presumably, the
developer wrote the method call for a reason -- they wanted their code
to do something. Nobody needs a fancy no-op in their code. So while
discarding "safe" return values does not compromise memory safety or
introduce races or anything bad like that, there is a very high
probability that the code is just wrong and does not do what the
developer wanted. It does something else, in a totally "safe" way.
Dmitri
···
On Tue, Mar 1, 2016 at 11:50 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org> wrote:
Whoa. Everyone seems to be in favor of this. Don't you guys always return
something ‘just in case’, in the best traditions of C API design? I tend to
have lots of discardable results and only a few where I might legitimately
forget to use it.
IMO, in most cases ignoring a return value is “safe”:
a) If a method is called only for its result, forgetting to use the result
won't really introduce any new bugs — if you're not using that missing
result elsewhere, storing it into a variable won't help.
b) If you're calling a method for its side effect, normally the result may
be discarded.
The only case where this matters is when the method establishes a long-term
relationship (like a subscription) that needs to be stored to survive. That
seems like a rare case.