[swift-evolution] [Proposal] Refining Identifier and Operator Symbology
Jonathan Hull
jhull at gbis.com
Thu Oct 27 15:04:39 CDT 2016
Just to play devil’s advocate (since I am honestly ok with the less draconian form of the proposal now), wouldn’t it be possible to declare the relevant unicode characters in the module’s plist (or similar file)? I know it isn’t the most elegant solution, but it does move the bar on using those characters from impossible to possible, and it would no longer mix up the compilation layers.
Thanks,
Jon
> On Oct 24, 2016, at 10:10 PM, Chris Lattner <clattner at apple.com> wrote:
>
>
>> On Oct 20, 2016, at 5:03 PM, Jonathan S. Shapiro via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> On Thu, Oct 20, 2016 at 12:25 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Would it be possible to do the following:
>>
>> • Have 1 group which are always used as identifiers. This would probably be the identifiers from this proposal.
>>
>> • Have a 2nd group which are always used as operators (quite a bit larger than the group proposed by this proposal). At a minimum, the following ascii + set operators + math operators:
>> (± ≠ ≤ ≥ ¿ ¡ ™ ¢ ¶ • ° ƒ © √ ∆ ◊ § ≈ ∫ ÷ ¬ ).
>>
>> • Everything else is in a 3rd group.
>>
>> No. This is far, far too complicated, and it mixes up the layers of the compilation process.
>
> Right. Any proposal that changes parser behavior based on a visible operator declaration will break the ability for Swift to separately compile files. This will have massive tooling ramifications that are almost certainly a non-starter.
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161027/99df0164/attachment.html>
More information about the swift-evolution
mailing list