1

IIRC the problems with C character literals began when they began to
generalize the original concept of representing a single ASCII character.

Repurposing 'x' to something like multiline strings might be confusing
to people migrating from other languages, but perhaps refocusing on the
original usage would not be?

IOW, 'x' where x must be a Character, that is, an extended Unicode
grapheme cluster — represented in the source code as UTF8 or with the \u
notation. A shortcut for typing Character("x").

···

On 12/14/15 20:40, swift-evolution-request@swift.org wrote:

Date: Mon, 14 Dec 2015 12:38:14 -0800
From: Chris Lattner <clattner@apple.com>
Subject: Re: [swift-evolution] multi-line string literals
Message-ID: <509AEA5D-81C8-48A5-B676-B059624ED4E3@apple.com>

> On Dec 11, 2015, at 4:03 PM, Travis Tilley <ttilley@gmail.com> wrote:
> Fair enough. Plus if Chris Lattner has any strong opinions about the behavior of single quotes, which might be the case given the existing code for handling them in Lexer.cpp, backticks are a damn good alternative. I'd still like to wait to hear back from him or someone else on the core team about that one.

Support for single quoted literals like 'x' was a legacy feature for C-like character literals that we explored before the design of Character went to where it is now. I’d be fine ripping it out and repurposing it.

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

2

We actually had this at one point, but it turned out that sometimes you wanted a Character and sometimes a UnicodeScalar, and in both cases your algorithm was probably wrong (cf. String is no longer a CollectionType). At that point it didn't offer any benefits over just regular string syntax, and it freed up the syntax for something else.

There's a fair amount of precedent for single-quoted strings being:
- single characters (C, Java, C#)
- unprocessed strings (shell scripts, Ruby)
- exactly the same as double-quoted strings (Python)

I (personally) wouldn't want them for multi-line literals, though.

Jordan

···

On Dec 16, 2015, at 5:24 , Rainer Brockerhoff via swift-evolution <swift-evolution@swift.org> wrote:

On 12/14/15 20:40, swift-evolution-request@swift.org wrote:

Date: Mon, 14 Dec 2015 12:38:14 -0800
From: Chris Lattner <clattner@apple.com>
Subject: Re: [swift-evolution] multi-line string literals
Message-ID: <509AEA5D-81C8-48A5-B676-B059624ED4E3@apple.com>

On Dec 11, 2015, at 4:03 PM, Travis Tilley <ttilley@gmail.com> wrote:
Fair enough. Plus if Chris Lattner has any strong opinions about the behavior of single quotes, which might be the case given the existing code for handling them in Lexer.cpp, backticks are a damn good alternative. I'd still like to wait to hear back from him or someone else on the core team about that one.

Support for single quoted literals like 'x' was a legacy feature for C-like character literals that we explored before the design of Character went to where it is now. I’d be fine ripping it out and repurposing it.

IIRC the problems with C character literals began when they began to
generalize the original concept of representing a single ASCII character.

Repurposing 'x' to something like multiline strings might be confusing
to people migrating from other languages, but perhaps refocusing on the
original usage would not be?

IOW, 'x' where x must be a Character, that is, an extended Unicode
grapheme cluster — represented in the source code as UTF8 or with the \u
notation. A shortcut for typing Character("x").

3

I agree that this would be weird syntax for multi-line literals:

let x = ‘
stuff
more stuff’

On the other hand, It could be a reasonable design to say that ‘xyz’ strings are a dual to “xyz” strings that disable escape expansion. If you did that, then you could end up with a world where multi-line strings could be either:

let x = “””
stuff with\tescapes \(42)
“””

and:

let x = ‘''
escapes\(42)not processed!\n
‘''

Please ignore the “smart” quotes above :-)

-Chris

···

On Dec 16, 2015, at 10:34 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

IOW, 'x' where x must be a Character, that is, an extended Unicode
grapheme cluster — represented in the source code as UTF8 or with the \u
notation. A shortcut for typing Character("x").

We actually had this at one point, but it turned out that sometimes you wanted a Character and sometimes a UnicodeScalar, and in both cases your algorithm was probably wrong (cf. String is no longer a CollectionType). At that point it didn't offer any benefits over just regular string syntax, and it freed up the syntax for something else.

There's a fair amount of precedent for single-quoted strings being:
- single characters (C, Java, C#)
- unprocessed strings (shell scripts, Ruby)
- exactly the same as double-quoted strings (Python)

I (personally) wouldn't want them for multi-line literals, though.

4

I said this during the Swift 1 runup, and I'll say it again: Python has a design for this stuff that works. They didn't make any changes to it between Python 2 and 3, so it has proven itself with many generations of programmer. I still don't see any reason to invent something new.

-Dave

···

On Dec 16, 2015, at 10:47 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 10:34 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

IOW, 'x' where x must be a Character, that is, an extended Unicode
grapheme cluster — represented in the source code as UTF8 or with the \u
notation. A shortcut for typing Character("x").

We actually had this at one point, but it turned out that sometimes you wanted a Character and sometimes a UnicodeScalar, and in both cases your algorithm was probably wrong (cf. String is no longer a CollectionType). At that point it didn't offer any benefits over just regular string syntax, and it freed up the syntax for something else.

There's a fair amount of precedent for single-quoted strings being:
- single characters (C, Java, C#)
- unprocessed strings (shell scripts, Ruby)
- exactly the same as double-quoted strings (Python)

I (personally) wouldn't want them for multi-line literals, though.

I agree that this would be weird syntax for multi-line literals:

let x = ‘
stuff
more stuff’

On the other hand, It could be a reasonable design to say that ‘xyz’ strings are a dual to “xyz” strings that disable escape expansion. If you did that, then you could end up with a world where multi-line strings could be either:

let x = “””
stuff with\tescapes \(42)
“””

and:

let x = ‘''
escapes\(42)not processed!\n
‘''

Please ignore the “smart” quotes above :-)

5

Great, thanks Jordan. I tried to search for this sort of historical
record but couldn't find it. Point taken.

···

On 12/16/15 16:34, Jordan Rose wrote:

On Dec 16, 2015, at 5:24 , Rainer Brockerhoff via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
to people migrating from other languages, but perhaps refocusing on the
original usage would not be?

IOW, 'x' where x must be a Character, that is, an extended Unicode
grapheme cluster — represented in the source code as UTF8 or with the \u
notation. A shortcut for typing Character("x").

We actually had this at one point, but it turned out that sometimes you
wanted a Character and sometimes a UnicodeScalar, and in both cases your
algorithm was probably wrong (cf. String is no longer a CollectionType).
At that point it didn't offer any benefits over just regular string
syntax, and it freed up the syntax for /something/ else.

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

6

The only point worth mentioning is that Python's syntax doesn't handle
indentation in a useful way. It's created a lot of trouble for me and
others over the years.

···

On Wed, 16 Dec 2015 at 10:58, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 10:47 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 16, 2015, at 10:34 AM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:

IOW, 'x' where x must be a Character, that is, an extended Unicode
grapheme cluster — represented in the source code as UTF8 or with the \u
notation. A shortcut for typing Character("x").

We actually had this at one point, but it turned out that sometimes you
wanted a Character and sometimes a UnicodeScalar, and in both cases your
algorithm was probably wrong (cf. String is no longer a CollectionType). At
that point it didn't offer any benefits over just regular string syntax,
and it freed up the syntax for *something* else.

There's a fair amount of precedent for single-quoted strings being:
- single characters (C, Java, C#)
- unprocessed strings (shell scripts, Ruby)
- exactly the same as double-quoted strings (Python)

I (personally) wouldn't want them for multi-line literals, though.

I agree that this would be weird syntax for multi-line literals:

let x = ‘
stuff
more stuff’

On the other hand, It could be a reasonable design to say that ‘xyz’
strings are a dual to “xyz” strings that disable escape expansion. If you
did that, then you could end up with a world where multi-line strings could
be either:

let x = “””
stuff with\tescapes \(42)
“””

and:

let x = ‘''
escapes\(42)not processed!\n
‘''

Please ignore the “smart” quotes above :-)

I said this during the Swift 1 runup, and I'll say it again: Python has a
design for this stuff that works. They didn't make any changes to it
between Python 2 and 3, so it has proven itself with many generations of
programmer. I still don't see any reason to invent something new.

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

let c:Character = “c” works fine today, as it implements ExtendedGraphemeClusterLiteralConvertible.

-DW

···

On Dec 16, 2015, at 6:24 AM, Rainer Brockerhoff via swift-evolution <swift-evolution@swift.org> wrote:

On 12/14/15 20:40, swift-evolution-request@swift.org wrote:

Date: Mon, 14 Dec 2015 12:38:14 -0800
From: Chris Lattner <clattner@apple.com>
Subject: Re: [swift-evolution] multi-line string literals
Message-ID: <509AEA5D-81C8-48A5-B676-B059624ED4E3@apple.com>

On Dec 11, 2015, at 4:03 PM, Travis Tilley <ttilley@gmail.com> wrote:
Fair enough. Plus if Chris Lattner has any strong opinions about the behavior of single quotes, which might be the case given the existing code for handling them in Lexer.cpp, backticks are a damn good alternative. I'd still like to wait to hear back from him or someone else on the core team about that one.

Support for single quoted literals like 'x' was a legacy feature for C-like character literals that we explored before the design of Character went to where it is now. I’d be fine ripping it out and repurposing it.

IIRC the problems with C character literals began when they began to
generalize the original concept of representing a single ASCII character.

Repurposing 'x' to something like multiline strings might be confusing
to people migrating from other languages, but perhaps refocusing on the
original usage would not be?

IOW, 'x' where x must be a Character, that is, an extended Unicode
grapheme cluster — represented in the source code as UTF8 or with the \u
notation. A shortcut for typing Character("x”).