> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution
>> <swift-evolution@swift.org> wrote:
>> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I
>> request we give a little more thought to the long term direction.
>>
>> My 2¢ is I’ve been convinced that very few characters are “obviously” either
>> a operator or identifier across all contexts where they might be used. Thus
>> relegating the vast majority of thousands of ambiguous characters to
>> committee to decide a single global usage. But that is both a huge time
>> sink and fundamentally flawed in approach due to the contextual dependency
>> of who is using them.
>>
>> For example, if a developer finds a set of symbols which perfectly denote
>> some niche concept, do you really expect the developer to submit a proposal
>> and wait months/years to get the characters classified and then a new
>> compiler version to be distributed, all so that developer can adopt his/her
>> own notation?
>
> The Unicode Consortium already has a document describing which Unicode
> characters are suitable identifiers in programming languages, with guidance
> as to how to customize that list around the edges. This is already adopted by
> other programming languages. So, with little design effort, that task is not
> only doable but largely done.
>
> As to operators, again, I am of the strong opinion that making it possible
> for developers to adopt any preferred notation for any purpose (a) is
> fundamentally incompatible with the division between operators and
> identifiers, as I believe you’re saying here; and (b) should be a non-goal
> from the outset. The only task, so far as I can tell, left to do is to
> identify what pragmatic set of (mostly mathematical) symbols are used as
> operators in the wider world and are likely to be already used in Swift code
> or part of common use cases where an operator is clearly superior to
> alternative spellings. In my view, the set of valid operator characters not
> only shouldn’t require parsing or import directives, but should be small
> enough to be knowable by memory.
The set notation operators should be identifiers, then? Because the impression
I got from the Set Algebra proposal a few months ago is that there are a lot of
people who’ve never even seen those operators, let alone memorized them.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
