> 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 <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
