Personally I prefer the requirement of spaces; if you require a method to have
textual operators without spaces then IMO it’s probably not a good place to use
a textual operator in the first place.
I like the space requirement as it essentially lets textual operators be custom
keywords, for example the recent thread on striding for loops, we could do the
following:
for eachIndex in 1 ..< 10 by 2 { … }
With the “by” defined as a custom operator on Range, rather than defining a new
keyword or for loop variant (since it’s still essentially a for in loop). It’s
really just a nicer alternative to: (1 ..< 10).by(2).
> On 28 Mar 2016, at 16:21, Thorsten Seitz via swift-evolution
> <[email protected]> wrote:
>
>> Am 08.01.2016 um 09:38 schrieb Jacob Bandes-Storch via swift-evolution
>> <[email protected] <mailto:[email protected]>>:
>>
>> 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.
>
> What about if • would have to begin and end an operator containing letters?
>
> x = a •times• b •mod• 8
>
> This looks more symmetrically (like Haskell’s backticks) and wouldn’t need
> the restriction to require spaces.
>
> Or maybe
>
> x = a ‹times› b ‹mod› 8
>
> Also easily typeable on a Mac keyboard.
>
>
>
>> 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.
>
> Indeed.
>
> -Thorsten
>
>
>> 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
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
>> <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
