Goal is to have something before Monday. I know that's not a lot of time
for review since it looks like we get a slot at the next EWG.

On Wed, Sep 16, 2020 at 9:27 AM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> On 9/16/20 1:59 AM, Corentin Jabot wrote:
>
>
>
> On Tue, Sep 15, 2020, 23:53 Tom Honermann <tom_at_[hidden]> wrote:
>
>> On 9/15/20 12:09 PM, Corentin Jabot via SG16 wrote:
>>
>>
>>
>> On Tue, Sep 15, 2020, 18:03 Steve Downey via SG16 <sg16_at_[hidden]>
>> wrote:
>>
>>> Thanks Corentin!
>>> I'll have these to chase down now. The problem I keep running into is
>>> making sure that the various proposals are adopted, and which ones
>>> have so many caveats that they aren't good examples. Python, Rust, and
>>> JS look solid.
>>>
>>
>> My understanding is that rust hasn't adopted it yet.
>>
>> Swift is a really good example of what NOT to do: some emojis are
>> considered symbols ( swift has arbitrary symbols) while some are considered
>> variable name.
>>
>> Swift does exactly what C++ currently does for identifiers. Compare:
>>
>> -
>> https://docs.swift.org/swift-book/ReferenceManual/LexicalStructure.html#ID412
>>
>> At the very bottom of the same page, swift describes operators.
> Which is not an issue C++ has
> So in Swift, ☹️ is an operator, 🙂 is an identifier.
> More description of the issue here
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160912/027112.html
>
> The takeaway is that a careless emoji support in identifiers impacts C++
> future ability to give special meaning to codepoints recognized as symbols,
> if we ever wanted to do that.
>
> Thanks, Corentin. That is a good point and there is some great analysis
> in the link you provided.
>
> Steve, I think we could benefit from blatantly stealing (and crediting of
> course!) some motivation from
> https://gist.github.com/jtbandes/c0b0c072181dcd22c3147802025d0b59.
> Specifically, noting that the current identifier allowances permit
> identifiers that look like operators and, as Corentin indicates, we may
> want to reserve those for use as future operators.
>
> Also, Steve, I recall you stating that you planned to put together some
> slides for the next EWG presentation. I would be happy to review and
> provide feedback/updates on those if you like.
>
> Tom.
>
>
>
>
>> - http://eel.is/c++draft/lex.name#1
>>
>> Tom.
>>
>>
>>> On Tue, Sep 15, 2020 at 11:44 AM Corentin Jabot via SG16
>>> <sg16_at_[hidden]> wrote:
>>> >
>>> > C#
>>> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/lexical-structure#identifiers
>>> (not exactly uax)
>>> >
>>> > Rust https://rust-lang.github.io/rfcs/2457-non-ascii-idents.html
>>> >
>>> > Swift
>>> https://forums.swift.org/t/a-path-forward-on-rationalizing-unicode-identifiers-and-operators/6735
>>> (not exactly uax)
>>> >
>>> > Erlang
>>> https://www.erlang.org/erlang-enhancement-proposals/eep-0040.html
>>> >
>>> > Julia https://docs.julialang.org/en/v1/manual/variables/ (not exactly
>>> uax)
>>> >
>>> > Python 3 https://www.python.org/dev/peps/pep-3131/
>>> >
>>> > JS https://tc39.es/ecma262/
>>> >
>>> >
>>> > On Tue, Sep 15, 2020, 17:23 Steve Downey via SG16 <
>>> sg16_at_[hidden]> wrote:
>>> >>
>>> >> I know we've discussed them before, but when trying to track down
>>> >> actual references for purposes of including in a paper, I keep failing
>>> >> at Google.
>>> >>
>>> >> Asking for help so that R7 will be better.
>>> >>
>>> >> PR's also welcome on
>>> https://github.com/steve-downey/papers/blob/master/d1949.md
>>> >> --
>>> >> SG16 mailing list
>>> >> SG16_at_[hidden]
>>> >> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>> >
>>> > --
>>> > SG16 mailing list
>>> > SG16_at_[hidden]
>>> > https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>> --
>>> SG16 mailing list
>>> SG16_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>>
>>
>>
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>