Andrew, thanks for comments. Yes, right now I see your points : its not
about mutation, but about the result type of the method/function with the
same mutation. I fully support this idea, as Swift allows to define the
same methods with just different types - we need handy way to call such
functions and clear rules when each one will be selected.
"method names help distinguish mutating and non-mutating methods."..
Just some my thoughts: I'm very skeptical in general on this. Personally I
probably prefer some kind of explicit "marker" on mutating methods(like
foo&.sort()), as I don't fully believe in idea of clear separation based on
naming rules. Not all, who will write open source libraries/projects, are
native English speakers and we'll have code where it will be hard to
distinguish based on names. Even in this swift-evolution list we have a lot
of discussions about right naming of the methods/functions in API..
On 26.04.2016 16:04, Andrew Bennett wrote:
Hi Vladimir, thanks for your feedback, I've put my responses inline:
On Tue, Apr 26, 2016 at 10:26 PM, Vladimir.S via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
Interesting suggestion, but IMO this will produce a question about new
naming conversion in Swift 3.0 (noun/verb, -ing/-ed, etc) because using
your suggestion we could want to use:
array.sort(..) // mutating
let array2 = array.sort(..) // non-mutating, instead of array.sorted()
This proposal does not want to change any naming guidelines. The reasons
for those guidelines is good, and remains the same. One reason is that
method names help distinguish mutating and non-mutating methods.
I'm happy to discuss making the proposal only apply to functions with the
same mutability if that alleviates your concern.
Also, technically we can assign a value to Void function(yes, compiler
warning will be produced, but just warning, not error):
var something = array.sort(..) // mutating,currently this is valid code
// something == ()
You're right, although I don't think there would be a worthwhile loss of
functionality if that statement chose a non-Void function, or didn't store
the result. I'm not sure why you would want to store the Void.
Note that this proposal is only to resolve ambiguity *if* there is any :)
It won't change how functions are resolved when there is no ambiguity.
On 26.04.2016 13 <tel:26.04.2016%2013>:56, Andrew Bennett via
swift-evolution wrote:
Hey,
I thought I would post another message to this thread because I
think it
was missed when I first sent it (I made the mistake of sending it
at 1am
San Francisco time, I'm in Australia).
I appreciate any feedback :)
Thanks,
Andrew
On Mon, Mar 28, 2016 at 7:21 PM, Andrew Bennett <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Swift can resolve functions based on the return type. However,
when the
result is unused a single function often can't be resolved without
explicitly specifying the type.
|func example() { ... } func example() -> Int { ... } example()
as Void
example() as Int |
This proposal disambiguates some cases:
* Preferring functions with a |*Void*| return type when the
result
*is* discarded.
* Preferring functions with a *non-|Void|* type when the
result *is
not* discarded.
These example will be unambiguous:
|example() // will prefer a `Void` function let x = example()
// will
prefer a non-`Void` function|
You can read the full latest version of the proposal here:
https://github.com/therealbnut/swift-evolution/blob/andrew-disambiguate-return-type/proposals/0000-disambiguate-return-type.md
This is the original version
<https://github.com/therealbnut/swift-evolution/blob/59d0f0b9bdabcfd675f36824232a8efa4a5f9152/proposals/0000-disambiguate-return-type.md>
of
the proposal.
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
