On 17/03/2015 12:42, Daniel Murphy wrote:
> "Nick Treleaven"  wrote in message news:me950a$2boc$1@digitalmars.com...
>
>> On 17/03/2015 03:28, Andrei Alexandrescu wrote:
>> > On a higher level: there's no subset of the language that's at the same
>> > time sufficiently complex and sufficiently obscure to make its
>> removal a
>> > net positive.
>>
>> q"" delimited strings. No one uses them (used once in all of Phobos).
>> They are obscure and add some complexity to lexing D.
>
> They don't have a high complexity though, and that's the point.  The
> amount of code in the compiler to support them is trivial.

They add complexity to tools such as ctags (written in C, the fishman fork supports D but not D-specific strings).

On Tue, 17 Mar 2015 12:00:09 +0000, Nick Treleaven wrote:

> On 17/03/2015 03:28, Andrei Alexandrescu wrote:
>> On a higher level: there's no subset of the language that's at the same time sufficiently complex and sufficiently obscure to make its removal a net positive.
> 
> q"" delimited strings. No one uses them (used once in all of Phobos). They are obscure and add some complexity to lexing D.

hello. let me introduce myself: i'm mr. NoOne!

On Tue, 17 Mar 2015 13:16:58 +0000, ketmar wrote:

> On Tue, 17 Mar 2015 12:00:09 +0000, Nick Treleaven wrote:
> 
>> On 17/03/2015 03:28, Andrei Alexandrescu wrote:
>>> On a higher level: there's no subset of the language that's at the same time sufficiently complex and sufficiently obscure to make its removal a net positive.
>> 
>> q"" delimited strings. No one uses them (used once in all of Phobos). They are obscure and add some complexity to lexing D.
> 
> hello. let me introduce myself: i'm mr. NoOne!

yet i must confess that it was once or twice, and mostly by accident. ;-)

On Tue, 17 Mar 2015 11:34:27 +0000, Biotronic wrote:

> On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
>> 0b1010 binary literals (even though C++11 supports them)
>> 0xABCD hex literals (but useful for porting C)
> 
> And while we're at it, why not remove those pesky base-10 literals as well? Shouldn't be too hard to write dec!"123456" instead of 123456. :p

i second that!

"Nick Treleaven"  wrote in message news:me98hl$2erf$1@digitalmars.com...

> They add complexity to tools such as ctags (written in C, the fishman fork supports D but not D-specific strings).

Yes, but only a very little bit.  How much code could you delete from a D lexer if they were removed? 

On Monday, 16 March 2015 at 21:32:45 UTC, Baz wrote:
> On Monday, 16 March 2015 at 16:45:25 UTC, Andrei Alexandrescu wrote:
>> On 3/16/15 9:29 AM, Baz wrote:
>>> On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:
>>>> Walter Bright:
>>>>
>>>>> Unfortunately, it needs to be a dropin replacement for x"...", which
>>>>> returns a string/wstring/dstring.
>>>>
>>>> This is bad. 99% of the times you don't want a string/wstring/dstring
>>>> out of a hex string:
>>>>
>>>> https://issues.dlang.org/show_bug.cgi?id=10454
>>>> https://issues.dlang.org/show_bug.cgi?id=5909
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> this is the API that's about to be proposed, it named as suggested by
>>> A.A., and it handles the two issues you point out:
>>>
>>> ---
>>> public string hexString(string hexData, bool putWhites = false)()
>>> public string hexString(dstring hexData, bool putWhites = false)()
>>> public string hexString(wstring hexData, bool putWhites = false)()
>>>
>>> public ubyte[] hexBytes(string hexData)()
>>> public ubyte[] hexBytes(dstring hexData)()
>>> public ubyte[] hexBytes(wstring hexData)()
>>> ---
>>
>> (Drop the "public", this ain't Java.)
>>
>> I don't see a necessity for the input string having different widths; string is enough. There may be a necessity to choose the width of the output with changes in function name, e.g. hexWString and hexDString.
>>
>> That opens the question whether we want only ubyte[] for hex bytes or all integral types.
>>
>>> additionally to x string, a template parameter allows to put raw whites,
>>> e.g
>>>
>>> ---
>>> assert(hexString!("30 30", true) == "0 1");
>>> assert(hexString!("30 31") == "01"); // standard x string
>>> ---
>>
>> I don't see a need for this.
>>
>>
>> Andrei
>
> I'd like to propose this:
>
> http://dpaste.dzfl.pl/044958878fd9
>
> But after reading D.Nadlinger mind about the whole thing i realize that's the opposite the things should be done in the opposite way.

still about

http://dpaste.dzfl.pl/044958878fd9

Despite of the personnal opinion over the idea of removing x strings from the lang and integrate them as a phobos template is there any particulur "no no no" that would automatically prevent this to be an acceptable PR (style, guidline, foreach vs range iterator, etc)?

Sorry to insist but this is the first time i try to propose something and i'm usually less strict with my own things.
Thx to reply, otherwise i give it up.

On Sunday, 15 March 2015 at 21:40:02 UTC, Walter Bright wrote:
> On 3/15/2015 2:34 PM, Walter Bright wrote:
>> P.S. Also need to include all the examples in the dlang reference as unittest
>> cases.
>
> Also, HexStrings can handle w and d postfixes. Use the lexer.c code for TOK::hexStringConstant() as a guide to be sure all the permutations are covered.

Hi, i propose this:

https://github.com/D-Programming-Language/phobos/pull/3058

Baz:

> https://github.com/D-Programming-Language/phobos/pull/3058

I suggest to replace "litteral" with "literal", as in computer science:
http://en.wikipedia.org/wiki/Literal_%28computer_programming%29

Bye,
bearophile

On Tuesday, 17 March 2015 at 16:55:53 UTC, bearophile wrote:
> Baz:
>
>> https://github.com/D-Programming-Language/phobos/pull/3058
>
> I suggest to replace "litteral" with "literal", as in computer science:
> http://en.wikipedia.org/wiki/Literal_%28computer_programming%29
>
> Bye,
> bearophile

Thx, fixed.
This was literally the world wide shame...

On 03/17/15 15:15, Daniel Murphy via Digitalmars-d wrote:
> "Nick Treleaven"  wrote in message news:me98hl$2erf$1@digitalmars.com...
> 
>> They add complexity to tools such as ctags (written in C, the fishman fork supports D but not D-specific strings).
> 
> Yes, but only a very little bit.  How much code could you delete from a D lexer if they were removed?

About 80 lines. Which can actually be a significant portion of a full lexer (~15%).
That still does not mean that they should go; they are useful, for example for
writing multiline embedded DSLs.
OTOH this would be just one more random weekly language change, so why not?

artur