Thread overview
[Issue 14073] Allow token strings to use other types of brackets as delimiters
Jan 28, 2015
Vladimir Panteleev
Jan 28, 2015
FG
Jan 28, 2015
Orvid King
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #1 from bearophile_hugs@eml.cc ---
(In reply to monkeyworks12 from comment #0)

>     auto t1 = crange!q{ 'a'..'z', 'A'..'Z', '0'..'9' };

>     auto t1 = crange!q['a'..'z', 'A'..'Z', '0'..'9'];

They look about the same to me. I don't see the need for this syntax extension. If we want to introduce new syntax it has to introduce a bigger gain (like the proposed [1,2]s syntax for fixed-size arrays).

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

--- Comment #2 from monkeyworks12@hotmail.com ---
(In reply to bearophile_hugs from comment #1)
> (In reply to monkeyworks12 from comment #0)
> 
> >     auto t1 = crange!q{ 'a'..'z', 'A'..'Z', '0'..'9' };
> 
> >     auto t1 = crange!q['a'..'z', 'A'..'Z', '0'..'9'];
> 
> They look about the same to me. I don't see the need for this syntax extension. If we want to introduce new syntax it has to introduce a bigger gain (like the proposed [1,2]s syntax for fixed-size arrays).

This is unrelated to my proposal, but can't you do something similar with templates?

template sa(T, T[] array)
if (isRValue!array)
{
    enum sa = array;
}

auto staticArr = sa![1, 2];

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

--- Comment #3 from monkeyworks12@hotmail.com ---
(In reply to monkeyworks12 from comment #2)
> template sa(T, T[] array)
> if (isRValue!array)
> {
>     enum sa = array;
> }
> 
> auto staticArr = sa![1, 2];

`enum sa = array` should be `enum T[array.length] sa = array`.

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com

--- Comment #4 from Vladimir Panteleev <thecybershadow@gmail.com> ---
> There is no ambiguity here lexer-wise as far as I know, as the q signifies that either a token string or a delimited string follows.

This is incorrect:

    enum q = 5;
    enum arr(int x) = new int[x];
    auto r = arr!q[3];

Same with q().

> Which I subjectively believe looks better and is more readable.

Even without ambiguity issues, I think this is not a strong enough argument to justify the added complexity for all the tools out there that have to process D source code (compilers, linters, formatters, syntax highlighters, etc.)

I would say that D has enough kinds of string literals.

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

--- Comment #5 from FG <home@fgda.pl> ---
q[] and q() would clash with the use of q as an identifier. Encountering a myriad of delimiters used for the same thing would also be confusing.

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

Orvid King <blah38621@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |blah38621@gmail.com

--- Comment #6 from Orvid King <blah38621@gmail.com> ---
D already has string literals with arbitrary delimiters (which, incidentally, are a massive pain to parse) I don't see anything this would do that those string literals can't.

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

--- Comment #7 from monkeyworks12@hotmail.com ---
(In reply to FG from comment #5)
> q[] and q() would clash with the use of q as an identifier. Encountering a myriad of delimiters used for the same thing would also be confusing.

Ah, you're right. I guess that by itself stops this in its tracks.

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

--- Comment #8 from monkeyworks12@hotmail.com ---
(In reply to Orvid King from comment #6)
> D already has string literals with arbitrary delimiters (which, incidentally, are a massive pain to parse) I don't see anything this would do that those string literals can't.

Yes, and I agree they are pretty bad. It would be nice to have something like Perl's delimited strings... Anyway, I'll close this.

--
January 28, 2015
https://issues.dlang.org/show_bug.cgi?id=14073

monkeyworks12@hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--