• is the dot product operator. Sent from my iPhone
> On Mar 28, 2016, at 10: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
