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 > <swift-evolution@swift.org> wrote: > >> Am 08.01.2016 um 09:38 schrieb Jacob Bandes-Storch via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> 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 >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution