Re: Replace core language HexStrings with library entity
On Sunday, 22 March 2015 at 10:36:27 UTC, Dicebot wrote: It was a response to question why vibe.d has reimplemented so many bits of Phobos without ever contributing it back. I apologize if it came off this way, I meant it as vibe shouldn't have to be reimplementing these things, they're already in the stdlib so there's an obvious issue here
Re: Replace core language HexStrings with library entity
On Saturday, 21 March 2015 at 00:30:42 UTC, Andrei Alexandrescu wrote: On 3/20/15 9:02 AM, Dicebot wrote: On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote: as an addendum, vibe.d reimplements huge amounts of phobos, is there a reason none of this is ever getting upstreamed? Getting something into Phobos is a huge commitment. Not documentation. For something widely used like json library the API discissions can destroy your spare time in blink of an eye. Sonke actually attempted to do that at some point, you can see http://forum.dlang.org/thread/lt5s76$is$1...@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com for what happened. What happened is that the design has been approved (I emailed Sönke personally) but he moved places so he didn't have time. Yes, it is a time commitment. When it wasn't you get things like std.json. It was a response to question why vibe.d has reimplemented so many bits of Phobos without ever contributing it back.
Re: Replace core language HexStrings with library entity
On 3/20/15 9:09 AM, Adam D. Ruppe wrote: On Friday, 20 March 2015 at 16:02:23 UTC, Dicebot wrote: Getting something into Phobos is a huge commitment. And it ties your hands and comes with all kinds of annoying trivial nonsense baggage like spaces vs tabs. I disagree with this characterization. When they do occur reviews are helpful. In this particular case a professional chooses spaces without so much as thinking about it. I have a hard enough time bringing myself to write small functions for phobos due to the sum total of these little pains. I certainly wouldn't want to go through that for a whole module, it is so much easier to just tell people to download the file from my own website. The short version is you'd do immense good if you chose to contribute to Phobos. Andrei
Re: Replace core language HexStrings with library entity
On 3/20/15 9:02 AM, Dicebot wrote: On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote: as an addendum, vibe.d reimplements huge amounts of phobos, is there a reason none of this is ever getting upstreamed? Getting something into Phobos is a huge commitment. Not documentation. For something widely used like json library the API discissions can destroy your spare time in blink of an eye. Sonke actually attempted to do that at some point, you can see http://forum.dlang.org/thread/lt5s76$is$1...@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com for what happened. What happened is that the design has been approved (I emailed Sönke personally) but he moved places so he didn't have time. Yes, it is a time commitment. When it wasn't you get things like std.json. Andrei
Re: Replace core language HexStrings with library entity
On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote: as an addendum, vibe.d reimplements huge amounts of phobos, is there a reason none of this is ever getting upstreamed? Getting something into Phobos is a huge commitment. For something widely used like json library the API discissions can destroy your spare time in blink of an eye. Sonke actually attempted to do that at some point, you can see http://forum.dlang.org/thread/lt5s76$is$1...@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com for what happened.
Re: Replace core language HexStrings with library entity
On Friday, 20 March 2015 at 16:02:23 UTC, Dicebot wrote: Getting something into Phobos is a huge commitment. And it ties your hands and comes with all kinds of annoying trivial nonsense baggage like spaces vs tabs. I have a hard enough time bringing myself to write small functions for phobos due to the sum total of these little pains. I certainly wouldn't want to go through that for a whole module, it is so much easier to just tell people to download the file from my own website.
Re: Replace core language HexStrings with library entity
On 18/03/2015 14:45, H. S. Teoh via Digitalmars-d wrote: On Wed, Mar 18, 2015 at 07:45:54PM +1100, Daniel Murphy via Digitalmars-d wrote: Kagamin wrote in message news:pltiewdojqrmgxrwh...@forum.dlang.org... The compiler lexer can be of arbitrary complexity, because it's already written. If you write a compiler, you just grab the ready lexer and use it, you don't need to count lines. The problem is with other, non-compiler tools. I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code. Not if we have libdmdlexer that they can reuse... ;-) Some tools can't require D due to project limitations.
Re: Replace core language HexStrings with library entity
On Wednesday, 18 March 2015 at 08:45:53 UTC, Daniel Murphy wrote: I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code. Language complexity matters for tools. Lexer complexity is only download and build, it doesn't matter what is the lexer, complexity is roughly the same, only compilation of bigger lexer can take longer if it has more lines.
Re: Replace core language HexStrings with library entity
On Tuesday, 17 March 2015 at 14:14:59 UTC, Daniel Murphy wrote: Yes, but only a very little bit. How much code could you delete from a D lexer if they were removed? The compiler lexer can be of arbitrary complexity, because it's already written. If you write a compiler, you just grab the ready lexer and use it, you don't need to count lines. The problem is with other, non-compiler tools.
Re: Replace core language HexStrings with library entity
Kagamin wrote in message news:pltiewdojqrmgxrwh...@forum.dlang.org... The compiler lexer can be of arbitrary complexity, because it's already written. If you write a compiler, you just grab the ready lexer and use it, you don't need to count lines. The problem is with other, non-compiler tools. I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code.
Re: Replace core language HexStrings with library entity
On Wed, Mar 18, 2015 at 07:45:54PM +1100, Daniel Murphy via Digitalmars-d wrote: Kagamin wrote in message news:pltiewdojqrmgxrwh...@forum.dlang.org... The compiler lexer can be of arbitrary complexity, because it's already written. If you write a compiler, you just grab the ready lexer and use it, you don't need to count lines. The problem is with other, non-compiler tools. I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code. Not if we have libdmdlexer that they can reuse... ;-) T -- A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth
Re: Replace core language HexStrings with library entity
On 3/17/15 5:45 PM, weaselcat wrote: On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:me9s2m$308v$1...@digitalmars.com... It pains me to no end to see energy going in all the wrong places. Just now I was reviewing some code using std.json. Most everybody admits that library could be improved or rewritten. There's been some work on the latter, which has not been pursued to completion. Until then, we've had for _years_ a mediocre - albeit let's say passable - implementation with a shockingly bad documentation - http://dlang.org/phobos/std_json.html has not ONE example, like literally not ONE line of code on it. It's been like that for YEARS. I'd find it difficult to imagine a simpler and more impactful way to contribute to D, than improving on that documentation. Just use vibe.d's json library. what is the point of having a half-assed version in the _standard_ library??? The irony is what's now is std is usable albeit meh, but so poorly documented it looks damn straight useless. I need to figure why folks willing to write small novels in this forum will neglect literally for years to apply some of that energy to D's documentation. -- Andrei
Re: Replace core language HexStrings with library entity
On 3/17/15 5:34 PM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:me9s2m$308v$1...@digitalmars.com... It pains me to no end to see energy going in all the wrong places. Just now I was reviewing some code using std.json. Most everybody admits that library could be improved or rewritten. There's been some work on the latter, which has not been pursued to completion. Until then, we've had for _years_ a mediocre - albeit let's say passable - implementation with a shockingly bad documentation - http://dlang.org/phobos/std_json.html has not ONE example, like literally not ONE line of code on it. It's been like that for YEARS. I'd find it difficult to imagine a simpler and more impactful way to contribute to D, than improving on that documentation. Just use vibe.d's json library. That was just an example. -- Andrei
Re: Replace core language HexStrings with library entity
On 3/17/2015 9:39 AM, Baz wrote: 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 Thanks!
Re: Replace core language HexStrings with library entity
On 03/17/15 22:18, Baz via Digitalmars-d wrote:
On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:
On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing them.
The only problem with the former is the lack of a non-brace-nesting
variant.
Lexing is quite trivial, as long as the lexer supports recursion.
For example, this is a complete implementation:
TokenString: q{ TokenStringBody }
TokenStringBody: ( ( ![{}] TokenClass )+ / BracedTokenSequence )*
BracedTokenSequence: { ( ( ![{}] TokenClass )+ / BracedTokenSequence
)* }
That's PEG, but the mapping to code should be fairly obvious.
For syntax highlighting purposes it can actually be even simpler - it's
enough to treat a `q{` token just like a `{`; everything that follows
No. I don't agree. `q{` makes sense: it's a helper for a string you want to
mix. `q{` means: don't highlight me as a string even if i'm one. It's clearly
made for the people who writes text editors and IDEs.
There must be some misunderstanding, because you actually fully agree
with me. :)
The only problem with token-strings is that there isn't a version that
lets you write /incomplete/ code sequences. Eg
q{ int blah(){ return } ~ text(42) ~ q{ ; } }
clearly isn't valid. What's missing is either a variant where {} don't
nest, or one that allows some kind of string interpolation.
artur
Re: Replace core language HexStrings with library entity
On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:
On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing them.
The only problem with the former is the lack of a
non-brace-nesting
variant.
Lexing is quite trivial, as long as the lexer supports
recursion.
For example, this is a complete implementation:
TokenString: q{ TokenStringBody }
TokenStringBody: ( ( ![{}] TokenClass )+ /
BracedTokenSequence )*
BracedTokenSequence: { ( ( ![{}] TokenClass )+ /
BracedTokenSequence )* }
That's PEG, but the mapping to code should be fairly obvious.
For syntax highlighting purposes it can actually be even
simpler - it's
enough to treat a `q{` token just like a `{`; everything that
follows
No. I don't agree. `q{` makes sense: it's a helper for a string
you want to mix. `q{` means: don't highlight me as a string even
if i'm one. It's clearly made for the people who writes text
editors and IDEs.
Re: Replace core language HexStrings with library entity
On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing them.
The only problem with the former is the lack of a non-brace-nesting
variant.
Lexing is quite trivial, as long as the lexer supports recursion.
For example, this is a complete implementation:
TokenString: q{ TokenStringBody }
TokenStringBody: ( ( ![{}] TokenClass )+ / BracedTokenSequence )*
BracedTokenSequence: { ( ( ![{}] TokenClass )+ / BracedTokenSequence )*
}
That's PEG, but the mapping to code should be fairly obvious.
For syntax highlighting purposes it can actually be even simpler - it's
enough to treat a `q{` token just like a `{`; everything that follows
will be valid D tokens.
artur
Re: Replace core language HexStrings with library entity
On Tuesday, 17 March 2015 at 21:31:58 UTC, Artur Skawina wrote:
On 03/17/15 22:18, Baz via Digitalmars-d wrote:
On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:
On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing
them.
The only problem with the former is the lack of a
non-brace-nesting
variant.
Lexing is quite trivial, as long as the lexer supports
recursion.
For example, this is a complete implementation:
TokenString: q{ TokenStringBody }
TokenStringBody: ( ( ![{}] TokenClass )+ /
BracedTokenSequence )*
BracedTokenSequence: { ( ( ![{}] TokenClass )+ /
BracedTokenSequence )* }
That's PEG, but the mapping to code should be fairly obvious.
For syntax highlighting purposes it can actually be even
simpler - it's
enough to treat a `q{` token just like a `{`; everything that
follows
No. I don't agree. `q{` makes sense: it's a helper for a
string you want to mix. `q{` means: don't highlight me as a
string even if i'm one. It's clearly made for the people who
writes text editors and IDEs.
There must be some misunderstanding, because you actually fully
agree
with me. :)
The only problem with token-strings is that there isn't a
version that
lets you write /incomplete/ code sequences. Eg
q{ int blah(){ return } ~ text(42) ~ q{ ; } }
clearly isn't valid. What's missing is either a variant where
{} don't
nest, or one that allows some kind of string interpolation.
artur
I'm completly drunk now and i dont understand what you mean...But
if we agree that token strings are not to be removed, then we
agree. We are on the same channel.
Re: Replace core language HexStrings with library entity
Andrei Alexandrescu wrote in message news:me870h$1fnc$1...@digitalmars.com... 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. Associative arrays come close, but only because of their insanely high complexity. Complex numbers are another one, although they can be safely ignored most of the time.
Re: Replace core language HexStrings with library entity
On 3/17/15 10:33 AM, Artur Skawina via Digitalmars-d wrote: 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? Well said. It pains me to no end to see energy going in all the wrong places. Just now I was reviewing some code using std.json. Most everybody admits that library could be improved or rewritten. There's been some work on the latter, which has not been pursued to completion. Until then, we've had for _years_ a mediocre - albeit let's say passable - implementation with a shockingly bad documentation - http://dlang.org/phobos/std_json.html has not ONE example, like literally not ONE line of code on it. It's been like that for YEARS. I'd find it difficult to imagine a simpler and more impactful way to contribute to D, than improving on that documentation. And that has nothing to do with the quality of generating e.g. template constraints etc. It's simply about a good soul writing some documentation. I wouldn't even be too bothered about it if only a handful of folks were working on D. But there's all this churn in the group, all this spinning of the wheels, all to so little outcome. Until we mobilize ourselves to get good work done, D doesn't deserve more notoriety than it has. Andrei
Re: Replace core language HexStrings with library entity
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
Re: Replace core language HexStrings with library entity
On Wednesday, 18 March 2015 at 00:45:56 UTC, weaselcat wrote: On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:me9s2m$308v$1...@digitalmars.com... It pains me to no end to see energy going in all the wrong places. Just now I was reviewing some code using std.json. Most everybody admits that library could be improved or rewritten. There's been some work on the latter, which has not been pursued to completion. Until then, we've had for _years_ a mediocre - albeit let's say passable - implementation with a shockingly bad documentation - http://dlang.org/phobos/std_json.html has not ONE example, like literally not ONE line of code on it. It's been like that for YEARS. I'd find it difficult to imagine a simpler and more impactful way to contribute to D, than improving on that documentation. Just use vibe.d's json library. what is the point of having a half-assed version in the _standard_ library??? as an addendum, vibe.d reimplements huge amounts of phobos, is there a reason none of this is ever getting upstreamed?
Re: Replace core language HexStrings with library entity
weaselcat wrote in message news:cfxrrvjnhlofsxpxx...@forum.dlang.org... as an addendum, vibe.d reimplements huge amounts of phobos, is there a reason none of this is ever getting upstreamed? Some of it is blocked waiting on other parts to be implemented, the rest is waiting for someone to champion it.
Re: Replace core language HexStrings with library entity
weaselcat wrote in message news:vlrwhuvaxxhsvvtdz...@forum.dlang.org... what is the point of having a half-assed version in the _standard_ library??? It predates vibe.d's version by many many years, and nobody has fixed or replaced it. As Andrei said, nobody has even bothered documenting it. It will most likely stay where it is until there is a suitable replacement.
Re: Replace core language HexStrings with library entity
Andrei Alexandrescu wrote in message news:me9s2m$308v$1...@digitalmars.com... It pains me to no end to see energy going in all the wrong places. Just now I was reviewing some code using std.json. Most everybody admits that library could be improved or rewritten. There's been some work on the latter, which has not been pursued to completion. Until then, we've had for _years_ a mediocre - albeit let's say passable - implementation with a shockingly bad documentation - http://dlang.org/phobos/std_json.html has not ONE example, like literally not ONE line of code on it. It's been like that for YEARS. I'd find it difficult to imagine a simpler and more impactful way to contribute to D, than improving on that documentation. Just use vibe.d's json library.
Re: Replace core language HexStrings with library entity
On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:me9s2m$308v$1...@digitalmars.com... It pains me to no end to see energy going in all the wrong places. Just now I was reviewing some code using std.json. Most everybody admits that library could be improved or rewritten. There's been some work on the latter, which has not been pursued to completion. Until then, we've had for _years_ a mediocre - albeit let's say passable - implementation with a shockingly bad documentation - http://dlang.org/phobos/std_json.html has not ONE example, like literally not ONE line of code on it. It's been like that for YEARS. I'd find it difficult to imagine a simpler and more impactful way to contribute to D, than improving on that documentation. Just use vibe.d's json library. what is the point of having a half-assed version in the _standard_ library???
Re: Replace core language HexStrings with library entity
On Tuesday, 17 March 2015 at 14:14:59 UTC, Daniel Murphy 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?
Not that much. But q{ string are a pain in the ass.
Re: Replace core language HexStrings with library entity
On Tue, Mar 17, 2015 at 07:47:05PM +, deadalnix via Digitalmars-d wrote:
On Tuesday, 17 March 2015 at 14:14:59 UTC, Daniel Murphy 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?
Not that much. But q{ string are a pain in the ass.
They are very useful for writing readable string mixins though. (Well,
string mixins themselves could also be construed to be a pain, so
*shrug*.)
T
--
Having a smoking section in a restaurant is like having a peeing section in a
swimming pool. -- Edward Burr
Re: Replace core language HexStrings with library entity
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
Re: Replace core language HexStrings with library entity
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.
Re: Replace core language HexStrings with library entity
On 17/03/2015 01:45, Daniel Murphy wrote: Nick Treleaven wrote in message news:me6jo4$ca$1...@digitalmars.com... 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in. Agreed they are more useful, but that does not necessarily mean they should be built-in.
Re: Replace core language HexStrings with library entity
On 17/03/2015 11:34, 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 Because all programming languages support integer literals.
Re: Replace core language HexStrings with library entity
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.
Re: Replace core language HexStrings with library entity
On Tue, 17 Mar 2015 11:34:27 +, 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! signature.asc Description: PGP signature
Re: Replace core language HexStrings with library entity
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).
Re: Replace core language HexStrings with library entity
On Tue, 17 Mar 2015 12:00:09 +, 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! signature.asc Description: PGP signature
Re: Replace core language HexStrings with library entity
On Tue, 17 Mar 2015 13:16:58 +, ketmar wrote: On Tue, 17 Mar 2015 12:00:09 +, 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. ;-) signature.asc Description: PGP signature
Re: Replace core language HexStrings with library entity
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?
Re: Replace core language HexStrings with library entity
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.
Re: Replace core language HexStrings with library entity
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
Re: Replace core language HexStrings with library entity
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
Re: Replace core language HexStrings with library entity
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...
Re: Replace core language HexStrings with library entity
On 3/16/2015 3:49 PM, Andrei Alexandrescu wrote: hexString just being there accessible for inspection is a good argument for its existence. People can use it as inspiration for their own abstractions. -- Andrei That's right. Being able to read in custom-formatted data into compile time literals is a big deal. It's a lot better than the way idgen.d (dmd compiler source) works.
Re: Replace core language HexStrings with library entity
On 3/16/15 3:02 PM, Adam D. Ruppe wrote: I really think users should learn the language more than the library if you know the implementation of hexString, you can do so much more with it than if you just know the function name. (this is also a benefit to this kind of function over a built in, of course) hexString just being there accessible for inspection is a good argument for its existence. People can use it as inspiration for their own abstractions. -- Andrei
Re: Replace core language HexStrings with library entity
On 3/16/15 6:45 PM, Daniel Murphy wrote: Nick Treleaven wrote in message news:me6jo4$ca$1...@digitalmars.com... 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in. Agreed. 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. Andrei
Re: Replace core language HexStrings with library entity
Nick Treleaven wrote in message news:me6jo4$ca$1...@digitalmars.com... 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in.
Re: Replace core language HexStrings with library entity
On Mon, 16 Mar 2015 14:22:38 +, Kagamin wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough. and i'll drop `*`. there is no reason to have multiply operator, we already have `+`! signature.asc Description: PGP signature
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 14:26:27 UTC, ketmar wrote: On Mon, 16 Mar 2015 14:22:38 +, Kagamin wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough. and i'll drop `*`. there is no reason to have multiply operator, we already have `+`! Just submit an implementation of templated `+` to phobos a +!5 b ;)
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough.
Re: Replace core language HexStrings with library entity
On 15/03/2015 19:46, Walter Bright wrote: Any other ideas on things that can removed from the core language and replaced with library entities? 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) Also, there are some things which I think are unnecessary: /++/ - If we made /**/ nest, /++/ would be unnecessary. It would potentially break code, but I think it would always cause a compiler error so breakage wouldn't be silent. I think good C code tends to avoid having /* /* */ comments (and instead uses #if 0 ... #endif). q'' non-nested delimited strings. Delimited strings seem to be quite rarely used, but the non-matching form I've never seem in the wild. Probably any intended use of these could instead use the q[] matching form or raw `` or heredoc strings instead.
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 21:44:38 UTC, Baz wrote: Yes, i'll send a PR tomorrow of tuesday. Thank you !
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 21:18:11 UTC, Baz wrote: On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A Thoughts? Anyone want to write the hex template? I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba Nitpick: Literal is spelled with one t.
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 07:45:16 UTC, Kagamin wrote: On Sunday, 15 March 2015 at 20:36:18 UTC, Marc Schütz wrote: On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote: http://dpaste.dzfl.pl/0f63623cc262a ? Wrong link? Or wrong thread? On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: Any other ideas on things that can removed from the core language and replaced with library entities? Ok, I get it now. But this replaces only `scope(exit)`. What about `scope(success)` and `scope(failure)`?
Re: Replace core language HexStrings with library entity
On 16/03/2015 14:22, Kagamin wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough. They need to nest in order to allow block comments in documentation blocks.
Re: Replace core language HexStrings with library entity
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)() --- 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 ---
Re: Replace core language HexStrings with library entity
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
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 21:40:25 UTC, Walter Bright wrote: BTW, the motivation for x strings is that dumpers often put out results like this: The nice thing about CTFE is it could literally just use that string and snip out the pieces as needed. I really think users should learn the language more than the library if you know the implementation of hexString, you can do so much more with it than if you just know the function name. (this is also a benefit to this kind of function over a built in, of course)
Re: Replace core language HexStrings with library entity
On Mon, 16 Mar 2015 22:02:38 +, Adam D. Ruppe wrote: I really think users should learn the language more than the library hear, hear! signature.asc Description: PGP signature
Re: Replace core language HexStrings with library entity
BTW, the motivation for x strings is that dumpers often put out results like this: : 80 14 0 12 43 3a 5c 63 62 78 5c 6d 61 72 73 5cC:\cbx\mars\ 0010: 74 6f 69 72 2e 63 0 88 6 0 0 9d 37 6e 4f 0toir.c..7nO. 0020: 88 6 0 0 a1 1 43 56 0 96 4c 0 0 4 46 4c..CV..L...FL 0030: 41 54 5 5f 54 45 58 54 4 43 4f 44 45 5 5f 44AT._TEXT.CODE._D 0040: 41 54 41 4 44 41 54 41 5 43 4f 4e 53 54 4 5fATA.DATA.CONST._ 0050: 42 53 53 3 42 53 53 7 24 24 54 59 50 45 53 6BSS.BSS.$$TYPES. 0060: 44 45 42 54 59 50 9 24 24 53 59 4d 42 4f 4c 53DEBTYP.$$SYMBOLS 0070: 6 44 45 42 53 59 4d 0 99 9 0 a9 d7 11 0 0.DEBSYM. 0080: 3 4 1 0 99 9 0 a9 78 10 0 0 5 6 1 0x... 0090: 99 9 0 a9 0 0 0 0 7 7 1 0 99 9 0 a9 00a0: 0 0 0 0 8 9 1 0 99 9 0 a1 15 e 0 0 00b0: c d 1 0 99 9 0 a1 e3 39 0 0 a b 1 0.9.. 00c0: 9a 2 0 2 0 91 73 0 0 1 2e 3f 69 6e 63 55..s?incU 00d0: 73 61 67 65 45 6c 65 6d 40 40 59 41 50 41 55 65sageElem@@YAPAUe 00e0: 6c 65 6d 40 40 50 41 55 49 52 53 74 61 74 65 40lem@@PAUIRState@ 00f0: 40 55 4c 6f 63 40 40 40 5a 10 0 0 0 0 36 3f@ULoc@@@Z.6? 0100: 67 65 74 45 74 68 69 73 40 40 59 41 50 41 55 65getEthis@@YAPAUe 0110: 6c 65 6d 40 40 55 4c 6f 63 40 40 50 41 55 49 52lem@@ULoc@@PAUIR 0120: 53 74 61 74 65 40 40 50 41 56 44 73 79 6d 62 6fState@@PAVDsymbo 0130: 6c 40 40 40 5a 7 1 0 0 0 0 95 1 2 0 1l@@@Z... and it's a giant pain to add all the \x notations, besides making it unreadably ugly.
Re: Replace core language HexStrings with library entity
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.
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 20:36:18 UTC, Marc Schütz wrote: On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote: http://dpaste.dzfl.pl/0f63623cc262a ? Wrong link? Or wrong thread? On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: Any other ideas on things that can removed from the core language and replaced with library entities?
Re: Replace core language HexStrings with library entity
On 3/16/15 11:54 AM, bearophile wrote: Andrei Alexandrescu: That opens the question whether we want only ubyte[] for hex bytes or all integral types. I suggest to implement only ubyte[] first. And wait for enhancement requests. At a minimum we need the built-in replacement. -- Andrei
Re: Replace core language HexStrings with library entity
Andrei Alexandrescu: That opens the question whether we want only ubyte[] for hex bytes or all integral types. I suggest to implement only ubyte[] first. And wait for enhancement requests. Bye, bearophile
Re: Replace core language HexStrings with library entity
On Monday, 16 March 2015 at 18:58:11 UTC, Andrei Alexandrescu wrote: I suggest to implement only ubyte[] first. And wait for enhancement requests. At a minimum we need the built-in replacement. -- Andrei cast(string)hex!… works just fine as a built-in replacement (where hex returns an ubyte array). Why should we repeat the same design mistake if we are going to break people's code anyway? — David
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 19:48:22 UTC, Walter Bright wrote: The motivation for this came from a post by deadalnix. And I'm obviously all for it :)
Re: Replace core language HexStrings with library entity
http://dpaste.dzfl.pl/0f63623cc262a ?
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A It'll simplify the core language slightly. Thoughts? Anyone want to write the hex template? Any other ideas on things that can removed from the core language and replaced with library entities? Can we make it so it returns a ubyte[]?
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote: http://dpaste.dzfl.pl/0f63623cc262a ? Wrong link? Or wrong thread?
Re: Replace core language HexStrings with library entity
The motivation for this came from a post by deadalnix.
Replace core language HexStrings with library entity
HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A It'll simplify the core language slightly. Thoughts? Anyone want to write the hex template? Any other ideas on things that can removed from the core language and replaced with library entities?
Re: Replace core language HexStrings with library entity
Marc Schütz: Can we make it so it returns a ubyte[]? There is an enhancement request on this (for the built in hex strings). Bye, bearophile
Re: Replace core language HexStrings with library entity
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.
Re: Replace core language HexStrings with library entity
On 3/15/15 12:46 PM, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A It'll simplify the core language slightly. Thoughts? Anyone want to write the hex template? Any other ideas on things that can removed from the core language and replaced with library entities? hexString and hexBytes. -- Andrei
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A Thoughts? Anyone want to write the hex template? I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba
Re: Replace core language HexStrings with library entity
On 3/15/2015 2:29 PM, bearophile wrote: There is an enhancement request on this (for the built in hex strings). A link would be helpful!
Re: Replace core language HexStrings with library entity
On Sun, Mar 15, 2015 at 11:32:04PM +0100, FG via Digitalmars-d wrote: On 2015-03-15 at 22:41, 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: Then maybe hex!... should produce the desired ubyte[] and something with a different name (for example hexString!...) would be the drop-in replacement for x..., returning a string. The more complex name being a hint that what you really need is hex. +1. I like this. I was quite disappointed when I first learned that x... returns a string rather than immutable(ubyte)[]. I have quite a number of use cases in mind where I'd want to specify hex values to represent binary data, but can't think of any where I'd want to do that to represent string data. Needing to use casts with x... just looks wrong. So using hex!... for immutable(ubyte)[] gets +1 from me. Leave hexString!... to emulate the current behaviour of x T -- War doesn't prove who's right, just who's left. -- BSD Games' Fortune
Re: Replace core language HexStrings with library entity
On 3/15/2015 2:18 PM, Baz wrote: On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A Thoughts? Anyone want to write the hex template? I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba I think you've got the right idea. Time for a pull request? P.S. Also need to include all the examples in the dlang reference as unittest cases.
Re: Replace core language HexStrings with library entity
On 2015-03-15 at 22:41, 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: Then maybe hex!... should produce the desired ubyte[] and something with a different name (for example hexString!...) would be the drop-in replacement for x..., returning a string. The more complex name being a hint that what you really need is hex.
Re: Replace core language HexStrings with library entity
Andrei Alexandrescu: hexString and hexBytes. -- Andrei Can you show me one or two different use cases of hexString? Bye, bearophile
Re: Replace core language HexStrings with library entity
On Sun, Mar 15, 2015 at 04:21:09PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/15/15 12:46 PM, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A It'll simplify the core language slightly. Thoughts? Anyone want to write the hex template? Any other ideas on things that can removed from the core language and replaced with library entities? hexString and hexBytes. -- Andrei Even better! T -- Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse
Re: Replace core language HexStrings with library entity
On 3/15/15 2:37 PM, Walter Bright wrote: On 3/15/2015 1:38 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Can we make it so it returns a ubyte[]? Unfortunately, it needs to be a dropin replacement for x..., which returns a string/wstring/dstring. That's what nice about library artifacts vs. language artifacts: you can add more of the former! Define hexBytes and hexString. -- Andrei
Re: Replace core language HexStrings with library entity
On 3/15/2015 1:38 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Can we make it so it returns a ubyte[]? Unfortunately, it needs to be a dropin replacement for x..., which returns a string/wstring/dstring.
Re: Replace core language HexStrings with library entity
On Sunday, 15 March 2015 at 21:34:22 UTC, Walter Bright wrote: On 3/15/2015 2:18 PM, Baz wrote: On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: HexStrings: http://dlang.org/lex.html#HexString They're rarely used, but very useful when needed. But, as the octal literals have shown, they can be easily replaced with a library template: x00 FBCD 32FD 0A becomes: hex!00 FBCD 32FD 0A Thoughts? Anyone want to write the hex template? I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba I think you've got the right idea. Time for a pull request? P.S. Also need to include all the examples in the dlang reference as unittest cases. Yes, i'll send a PR tomorrow of tuesday.
Re: Replace core language HexStrings with library entity
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
Re: Replace core language HexStrings with library entity
On 3/15/2015 2:44 PM, Baz wrote: Yes, i'll send a PR tomorrow of tuesday. Good!
Re: Replace core language HexStrings with library entity
On 3/15/2015 4:28 PM, Andrei Alexandrescu wrote: That's what nice about library artifacts vs. language artifacts: you can add more of the former! Define hexBytes and hexString. -- Andrei Yup. Should resist the urge to fix hexString, just make it a dropin replacement.
