Scala allows a method with one argument to be used infix with spaces either side, this would allow
for index in 1 ..< 10 by 2 { ... } if Range had a by method. This feature has proved popular in Scala. -- Howard. On 29 March 2016 at 21:37, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > 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>: > > 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> 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 >> 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 > > > > _______________________________________________ > 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