> On Nov 14, 2016, at 5:48 AM, Haravikk via swift-evolution > <[email protected]> wrote: > > I'm a +1 on the feature, though for simply handling symmetry it's not a super > critical issue. > > > I wonder though, when you start looking at symmetry is it worth looking at > other patterns? For example, could symmetrical operators be covered by a > broader multi-part operator definition? > > I was thinking recently it would be convenient if I could define say a > 3-dimensional point like so: <x, y, z> > > In this case you're looking at a symmetric operator with two different > components (opening and closing angle brackets) with the ability to take > three arguments. Is there a way we could define and implement something along > these lines? If so it would be very flexible, and potential allow us to unify > all operators into a single format. > > For example, you can thing of a prefix operator as being a leading symbol > plus one argument, while a postfix is one argument plus a trailing symbol, a > binary operator is an argument, a symbol and another argument, a symmetric > operator is a leading symbol, an argument and a trailing symbol (doesn't have > to be identical). > > If we had a means of specifying operators in this way (as a complete pattern) > we could do away with special cases of operators entirely, though they may be > worth keeping for compatibility and as a shorthand. +11
I would *love* to be able to specify "complex operators" that take more than two arguments, are “symmetric” (in Haravikk’s sense of the word, like "let y = |x|”), or really have whatever syntax I want. The difficulty would be doing it in such a way that it doesn't conflict with the existing grammar. This sounds difficult (to me, anyway), but it turns out that if we can represent operators’ grammar as regular expressions, it might be a more-or-less solved problem (http://stackoverflow.com/questions/3410256/regex-determine-if-two-regular-expressions-could-match-for-the-same-input). Now, actually finding a useful “complex” syntax that doesn’t conflict with anything might be tricky, but that’s not the language’s problem. - Dave Sweeris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
