On Oct 3, 2017, at 21:47, Chris Lattner <clatt...@nondot.org
<mailto:clatt...@nondot.org>> wrote:
>
>> On Oct 3, 2017, at 4:05 PM, David Sweeris <daveswee...@mac.com
>> <mailto:daveswee...@mac.com>> wrote:
>>
>>
>>> On Oct 2, 2017, at 10:06 PM, Chris Lattner <clatt...@nondot.org
>>> <mailto:clatt...@nondot.org>> wrote:
>>>
>>> On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
Oh! I didn't realize the proposal had already been written! Yeah, that clears
things up quite a bit, thanks for posting it :-)
Xiaodi Wu, I’m sorry I ever doubted you :-)
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
