> On Oct 3, 2017, at 4:05 PM, David Sweeris <[email protected]> wrote: > > >> On Oct 2, 2017, at 10:06 PM, Chris Lattner <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >>>> Keep in mind that Swift already goes far above and beyond in terms of >>>> operators >>> Yep, that's is a large part of why I'm such a Swift fan :-D >> >> Fortunately, no one is seriously proposing a major curtailing of the >> capabilities here, we’re just trying to rationalize the operator set, which >> is a bit of a mess at present. > I guess I don't really understand why it's currently "a bit of a mess”.
Read the motivation/inconsistency section of: https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/NNNN-refining-identifier-and-operator-symbology.md <https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/NNNN-refining-identifier-and-operator-symbology.md> >> Set algebra is an illustrative example, because it is both used by people >> who are experts and people who are not. As far as policies go, I think it >> makes sense for Swift libraries to define operator-like things as named >> functions (e.g. “intersection") and also define operators (“∩”) which can >> optionally be used in source bases that want them for convenience. The >> compiler and language cannot know whether a code base is written and >> maintained by experts who know the symbols and who value their clarity (over >> the difficulty typing and recognizing them), and this approach allows >> maintainers of the codebase to pick their own policies. > Oh, yeah, I can't imagine a situation in which I'd think it'd be a good idea > to not define a named function to go along with a unicode operator. I'm > mainly concerned that we not limit the people in 5) unless we need to. And to > be clear, if we actually need to, then I'm fine with doing that... It's just > that -- like I said earlier in this message -- I don't clearly understand why > this is a problem. Sure, that’s fair. This is an issue we’ve been tracking since the Swift 2.x (!) days, so there is a lot of context that is probably not immediately obvious if you haven’t been following it since then. The proposal link above talks about the damage that we still carry. >> I do think that Ethan’s suggestion upthread interesting, which suggest >> considering something like: >> import matrixlib (operators: [ᵀ,·,⊗]) >> >> Three concerns I see: >> - Requiring them today would be a source incompatibility with Swift 4 > If we leave the current "import everything" behavior as the default, why > would it be a source-breaking change? It’s not clear to me that leaving that as the default would actually add anything useful, because if that is the default, noone will opt into typing more gunk into their code for no reason. -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
