[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[André Videla]

> On 31 Aug 2017, at 23:50, Dave DeLong <delong at apple.com> wrote:
> 
> wonder if I need to go back to school for a degree in Math just to understand what’s going on.

To be fair, that’s probably the case. The project is quite extreme (an implementation of System F, I think Robert Widmann did one in Swift as well), and I can’t understand it either regardless of syntax. But the point of the example still stands: To show how extreme you can go with unicode. And from it, spark some discussion.

I agree that using unicode syntax is a higher barrier for entry, which goes against the goal of swift to be an easy to learn language.

Nevertheless, I disagree with your matrix example. We already use things like `+` for “things that we can add together` whatever `add` might mean. So the same operator is used for (Int, Int) -> Int as for (Double, Double) -> Double. I do not think it’s a stretch to expect users to know that matrices are “addable” togethers. Moreover, I would expect that a matrix API provides both an infix operator as well as a named function for manipulating matrices.

Furthermore, I would argue that using `+` for matrices is more consistent than the current definition of `+`. 
Indeed, the operator `+` is both used for combining numbers and combining arrays/strings. The inconsistency comes from the fact that it is expected that `+` is a commutative operator, but concatenation is not a commutative operation. Therefore the semantics of `+` varies depending on the types that it’s used on. And, in my opinion, this inconsistency is to be avoided when dealing with operators. Not to mention that nothing prevent a library to override `+` with any nonsensical behaviour.

Something I could imagine is deprecate operator overloading and constrain them to a single Type. For example, the operator `+` could be constrained to the protocol `Addable` and has the signature `infix func + (Self, Self) -> Self` and is commutative. Similarly, we could have a protocol `Concatenable` which has its own operator (e.g.: ++ ) and is not commutative. (those are secretely `CommutativeMonoid` and `Monoid`). This would allow different operators to represent different semantics and have them (loosely) enforced, so that nobody can declare something unexpected like `func + (Int, Array) -> ()`.

In conclusion, I think that the current state of operators should be improved in some way, regardless of better support for unicode or not. I realise my stance is quite extreme but I think that it is valuable to talk about it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170901/373198d9/attachment.html>