Only """string""" would have had me talking to God on the big white telephone (I'm learning Australian, and that means "puking"), so am perfectly content. r"string" is a good one. @"string" was also good, but on balance I think it's nicer to ape Python than C#. ;)

"Walter" <walter@digitalmars.com> wrote in message news:bg70ml$2oo8$1@digitaldaemon.com...
> This has been a most entertaining discussion, with a lot of great ideas.
But
> I have to pick one. I personally liked the `string`, but there are too
many
> problems with it, such as unreadable fonts, using a non-C character, etc. The """string""" was just too ugly for me (sorry).
>
> That leaves r"string" for wysiwyg string literals. The justifications are (thanks to Mark, etc., who pointed them all out):
>
> 1) It sticks to the C character set.
> 2) No problems with different fonts.
> 3) Establishes a precedent for new types of special strings.
> 4) Easy to tokenize.
> 5) There's precedent experience with it in other languages, such as
Python.
>
>

Walter wrote:
> That leaves r"string" for wysiwyg string literals. The justifications are
> (thanks to Mark, etc., who pointed them all out):

Good. How do i insert a " in such a string? Perhaps with ""?

-i.

Matthew Wilson wrote:

> Only """string""" would have had me talking to God on the big white
> telephone (I'm learning Australian, and that means "puking"), so am
> perfectly content. r"string" is a good one. @"string" was also good, but on
> balance I think it's nicer to ape Python than C#. ;)

I agree.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bg729k$2qfc$1@digitaldaemon.com...
> Walter wrote:
> > That leaves r"string" for wysiwyg string literals. The justifications
are
> > (thanks to Mark, etc., who pointed them all out):
> Good. How do i insert a " in such a string? Perhaps with ""?

Two ways:

r"string" \" r"more"
"string\"more"

Walter wrote:

>>Likewise with preferring a function which takes a
>>single character argument over a function which takes a string.
> 
> 
> I can see many uses for such overloading. Also, there's:
>     char[23] a;
>     a[] = "b";
> If "b" is a string, then a[] is set to "b\0\0\0\0\0....". If "b" is a single
> character, then a[] is set to "bbbbbb...";

No, the first's a length mismatch; "Error: lengths don't match for array
copy".  It's a good error, results in a little overspecification at
times, but keeps the nonsense code down.

I'm glad this is the choice. I was worried (just a little) that
we were going to end up with something ugly and complicated.

Walter wrote:
> This has been a most entertaining discussion, with a lot of great ideas. But
> I have to pick one. I personally liked the `string`, but there are too many
> problems with it, such as unreadable fonts, using a non-C character, etc.
> The """string""" was just too ugly for me (sorry).
> 
> That leaves r"string" for wysiwyg string literals. The justifications are
> (thanks to Mark, etc., who pointed them all out):
> 
> 1) It sticks to the C character set.
> 2) No problems with different fonts.
> 3) Establishes a precedent for new types of special strings.
> 4) Easy to tokenize.
> 5) There's precedent experience with it in other languages, such as Python.
> 
> 

Walter wrote:

> That leaves r"string" for wysiwyg string literals. The justifications are
> (thanks to Mark, etc., who pointed them all out):

If RE had an escape for the double-quote that would be even more helpful; \q is available and not used in Python RE or Perl RE.

"Frank Wills" <name@host.com> wrote in message news:bg84t6$ujs$1@digitaldaemon.com...
> I'm glad this is the choice. I was worried (just a little) that we were going to end up with something ugly and complicated.

I hate ugly and complicated, that's why I'm doing D <G>.

Walter wrote,

>1) It sticks to the C character set.
>2) No problems with different fonts.
>3) Establishes a precedent for new types of special strings.
>4) Easy to tokenize.
>5) There's precedent experience with it in other languages, such as Python.

6) Permits qualifiers such as n (null), hN (length header of size N bytes),
and pN (pad to next Nth byte).  These fine-tuning controls could become
important without C's single-quote 'abcd' construct.  Here are some C
language translations.

D proposed              ANSI C

r"string"          --> 'string'
rn"string"         --> 'string\0'
rh2"string"        --> '\0\6string'
rh4"string"        --> '\0\0\0\6string'
rh7"string"        --> '\0\0\0\0\0\0\6string'
rh4n"string"       --> '\0\0\0\6string\0'
rp4"string"        --> 'string\0\0'
rnp4"string"       --> 'string\0\0'

Python also has u for Unicode, which I would simply copy like r.

Maybe going over the top here, I suggest that all of these have command line default settings so that the meaning of r can be set once and forgotten.  The - symbol could be used to override in the source code for special cases.

rn- means turn off null even if defaulted 'on'
rh- means turn off header
rp- means turn off padding
rn-h-p- means turn off all

The b and x strings would address a serious need in embedded work and could benefit from the header and padding qualifiers.

Strings should concatenate by simple juxtaposition.  That behavior enables embedded comments:

// comment
myVar = x"ABCD 0000"
// another comment
x"FFFF BCDA"
// a final comment
;

means

myVar = x"ABCD0000FFFFBCDA";

Word alignment issues would be decided after concatenation, not before.  Strings concatenate bit by bit.

Mark

Different string types concatenate, too:

myVar = x"0123" r"string";  -->  myVar = '\0\1\2\3string';

while

myVar = x"0123" r"string" b"101";

creates an 83-bit entity whose alignment issues are open to discussion, but should be controllable.  Then D will be a real systems language.

Mark