[swift-evolution] Utilizing arguments without meaningful internal names

Dany St-Amant dsa.mls at icloud.com
Fri Feb 5 19:58:38 CST 2016

> Le 5 févr. 2016 à 20:18, Jessy Catterwaul via swift-evolution <swift-evolution at swift.org> a écrit :
>> How do you handle overloading? `let` shadows, while `func` overloads.
> It does now, but closures can’t currently be overloaded, which doesn’t make sense. You can’t store two overloads in closures that have the same names as those functions. This must end at some point.
>> Also, what is actually gained by eliminating the keyword marking functions as different from constants?
> Simplicity. Having both functions and closures in the language is complexity. I doubt it’s needed but haven’t heard otherwise.
> https://forums.developer.apple.com/thread/16594
>> So, how many people know how to type ƒ? I sure don’t.
> There aren’t that many keys on a keyboard and only using them leads to nonsense like $0. Hold option and type F. It’s easier to learn than making any Swift compile.

And where does one find the option key on standard PC running Linux or Windows (when using for example the IBM Swift Sandbox). It have been a few time I see people suggest using some fancy unicode character easily accessible on my preferred device keyboard but which are nearly impossible to type on typical no Apple devices. Call me old fashion but the standard keywords and symbols provided by the language should be limited to plain ASCII which can be used from any standard QWERTY keyboard without any fancy Apple-ism. I know not everyone use QWERTY; And from limited experience (I switch the mapping on the first swear), I know that it’s a pain to write code on a keyboard like French-Canadian, on which I can never find those dreadful curly-braces or even the slash. I do not want to bring this pain with me (and to others) when playing with Swift on a non-Apple device.

Sorry for the ranting,

>>> 3. $ is ugly and should be changed to .
>> Which already has a different meaning, looking up a static property or method on the contextually expected type.
> No, you can’t have a static property named with a number.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list