[swift-evolution] Allowing Characters for use as Custom Operators

Jacob Bandes-Storch jtbandes at gmail.com
Fri Jan 8 02:38:36 CST 2016

I'd be hesitant to support something like this. • is a very natural choice
for a binary operator by itself, and restricting it to require the use of
spaces seems unfortunate.

Re: free functions vs. methods: why does this matter? Supposing `foo` were
the syntax (bad choice, because it already has another meaning, but bear
with me), then you could disambiguate "a `foo` b" vs "a `self.foo` b" just
as you can with regular function calls.

Re: named parameters: there are two clear choices:
- Restrict such a syntax to functions without named parameters (seems
acceptable to me).
- Ignore parameter names, allowing any binary function to be used
(challenges with disambiguation, which I believe has had some discussion in
the other thread about function names).

This might be a crazy idea, but is it possible to support "a myfunc b"
without any extra delimiters? As far as I can tell, there's currently no
way this could parse as a valid expression, so there's no ambiguity to
resolve, although I imagine it would be hard to make diagnostics work well.
I'm not sure how this would play with precedence, but that hasn't been
discussed for any of the other solutions either.

Jacob Bandes-Storch

On Fri, Jan 8, 2016 at 12:29 AM, Jo Albright via swift-evolution <
swift-evolution at swift.org> wrote:

> The rationale is the same - the design of Swift really wants operators and
> identifiers to be partitioned into different namespaces.  Violating that
> would make it impossible to parse a swift file without parsing all of its
> imports.  This is a mistake that C made (you have to parse all the headers
> a file uses to reliably parse the file) that we don’t want to replicate in
> Swift.
> Thanks Chris. I now understand the reasoning for separating the two
> groups. I don’t have a background in language creation, so whatever I can
> learn from these email lists is awesome. I have already gained a ton of
> knowledge following these conversations.
> Alternative: Reserve one of the operator characters as an operator
> introducer. Everything from that character to the next whitespace is an
> operator name. This would allow non-operator characters in operator names
> while still preserving the strict operator/identifier separation.
>    // • is the operator introducer character
>    infix operator •times …
>    infix operator •mod …
>    x = a •times b •mod 8
> Limitations:
> You still can't use an unadorned word as an operator name.
> You can't use such an operator without whitespace (unlike operators whose
> names use operator characters only).
> Oooooo … that is a very cool alternative Greg. Honestly went into this
> proposal thinking there was no possibility, but now I have a glimmer of
> hope.
> Using “•” (option + 8 on keyboard) would be great since it is accessible
> through key combo, but isn’t widely used in normal expressions.
> What is needed to prove worth of such a feature to be added?
>  Nerd . Designer . Developer
> Jo Albright
> _______________________________________________
> 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/20160108/4691baa3/attachment.html>

More information about the swift-evolution mailing list