[swift-evolution] Taking advantage of our character space

[Xiaodi Wu]

On Fri, Oct 7, 2016 at 6:22 PM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> This is a quick one.  It would be nice to take advantage of all the
> wonderful characters that swift can use.  Not only unicode, but some of the
> less-used ASCII as well.
>
> In particular, I would like to see:
>
> 1) Allow the ‘π’ character as a FloatingPoint literal.  We can use
> CGFloat.pi and Double.pi right now, and I am not asking to replace that
> (since depending on the nationality of your keyboard, it can be simple or
> difficult to type), but π just reads much better. Would be good to have it
> as an option.  It would also be nice to be able to combine it with numbers
> in the literal (e.g. 2π)
>
> 2) Allow ≤, ≥, ≠ for less than or equal, greater than or equal, and not
> equals.  This was one of the first extensions I made when I began using
> swift.  I would really like to be able to use it in frameworks as well.
> Again, it doesn’t need to replace <=, >=, !=, it just adds polish and
> readability for those who want to use it.  You can even use my extension on
> comparable if you so desire.
>
> When I brought this up before there was push-back because it would
> "clutter the namespace".  I don’t think that is a valid argument though
> because any other use of the symbols π, ≤, ≥, and ≠ would be downright
> confusing. If you are creating a variable named ‘π’ and sticking something
> other than pi in it, that is just asking for trouble.  Same with the
> operations.  May as well use them for the one thing they make sense for…
>
> Also, little touches are what make a language enjoyable.
>

I can certainly see why it would be enjoyable to have these aliases.
However, it'd be rather a niche thing. IMO, the reason for avoiding their
addition to the standard library isn't just some aversion to "cluttering"
the namespace, as though another person might come along and want to use
Greek letter pi for some other purpose, but rather that a smaller API
surface area is straightforwardly easier to maintain than a larger one, and
these aren't obvious wins that merit additional API.


> Thanks,
> Jon
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161007/61da509f/attachment.html>