[swift-evolution] Allow ' in variable/constant names?

[Tony Allevato]

This particular case doesn't quite relate to the URL literal/regex
discussion, which would require a complex new static evaluation feature.
For this, the compiler *already has* logic
<https://github.com/apple/swift/blob/master/lib/Sema/CSApply.cpp#L1893> to
determine whether a string literal is expressible as a UnicodeScalar, a
Character, or a String; it's just applied differently when you write
`Character("ax")` vs. `"ax" as Character`, presumably because of the way
the type checker resolves the former to be calling the initializer that
takes a String and thus only treats the literal as a String.

In fact, I recall that John McCall raised this exact issue a while back in
the context of integers:

"[swift-evolution] Proposal: 'T(literal)' should construct T using the
appropriate literal protocol if possible"
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019950.html

Wherein the following expression that looks valid traps at runtime because
it tries to convert the literal to an Int first (which is signed and
therefore overflows) before calling the UInt64 initializer:

    let x = UInt64(0x8000_0000_0000_0000)

We've gotten a bit off-topic from the original point of this thread, but
this seems like an item that should be revisited soon, especially if it has
ABI consequences. I wonder if John or another core team member can chime in.

On Wed, Jan 11, 2017 at 9:53 PM David Sweeris <davesweeris at mac.com> wrote:

>
> On Jan 11, 2017, at 23:12, Tony Allevato <tony.allevato at gmail.com> wrote:
>
>
>
> On Wed, Jan 11, 2017 at 6:46 PM Jay Abbott via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME,
> DOUBLE PRIME, and TRIPLE PRIME - which makes more sense than an apostrophe.
> Now if only there were a keyboard that had a touch-screen at the top which
> could be used for typing context-sensitive characters that would otherwise
> be difficult to type. So yeah, solution is to make characters easier to
> type, not modify the language. If like me you don't have such a keyboard,
> you can always use ctrl+⌘+<space> and type ‘PRIME’ to find it, then pick
> it from recently used/favourites.
>
> Regarding the other point, I agree that character literals would be handy,
> but again I’m not sure if apostrophe is the right character to indicate it.
> Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
> SINGLE QUOTATION MARK would be better, they can be relatively easily typed
> with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
> into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.
>
> I'm not entirely convinced that we *need* special Character literals. The
> type checker is already able to treat a double-quoted string literal as a
> String, Character, or UnicodeScalar based on context in most places.
> Wouldn't it be more valuable to fill the gaps, like Charlie Monroe
> mentioned above, where these work:
>
>     let c: Character = "a"
>     let c = "a" as Character
>
> and this is caught as an error by the compiler:
>
>     let c: Character = "ax"
>
> but this slips through and crashes at runtime?
>
>     let c = Character("ax")
>
> I wonder what improvements could be made in the compiler to have that last
> one do something more appropriate than just call Character.init(String),
> which causes the runtime error.
>
>
> This reminds me of the "URL literal" thread. I believe the two ideas were
> essentially to add regex support to the compiler, add support for compiler
> "validation" of literals through compile-time functions, or both.
>
> IIRC, it was decided that both ideas were at least out of scope for phase
> 1 (I don't recall if this specific issue was brought up as a potential use
> case, though... unlike `Character`, `URL` isn't part of the stdlib).
>
> - Dave Sweeris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170112/4faacb95/attachment.html>