On Wednesday, 27 April 2016, Vladimir.S via swift-evolution < [email protected]> wrote:
> 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. > > I'm glad we are on the same page, please let me know if there's some way I can clarify the proposal :) > "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.. > > I agree, there's room to improve that. I don't think it's in scope for this proposal though, unless you feel this propasal causes issues. > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
