On 2/11/18 4:48 PM, Walter Bright wrote:
I also notice that hex strings are not simply equivalent to strings
with \x in them -- the latter is more constrained, as it must be a
pair of hex digits per \x. hex strings allow spaces between them.
The idea was to be able to cut text from things
On 2/11/2018 6:09 AM, Steven Schveighoffer wrote:
On 2/8/18 3:49 PM, Walter Bright wrote:
That would be a language change proposal or bug report. By all means, please
do so.
https://issues.dlang.org/show_bug.cgi?id=18420
Good!
I also notice that hex strings are not simply equivalent to
On 2/8/18 3:49 PM, Walter Bright wrote:
On 2/8/2018 10:42 AM, Steven Schveighoffer wrote:
On 2/8/18 1:25 PM, Walter Bright wrote:
"abc" is an array (it's an immutable(char)[]). There's no reason why
['a','b','c'] should be different than "abc" (other than the hidden
null character, which is
On 2/8/2018 10:42 AM, Steven Schveighoffer wrote:
On 2/8/18 1:25 PM, Walter Bright wrote:
"abc" is an array (it's an immutable(char)[]). There's no reason why
['a','b','c'] should be different than "abc" (other than the hidden null
character, which is irrelevant here).
['a','b','c'] is
On 2/8/2018 10:49 AM, Steven Schveighoffer wrote:
On 2/8/18 1:42 PM, Ralph Doncaster wrote:
On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote:
db 0ffdeh,0ffadh,0ffbeh,0ffefh ;
But it looks like they are all dchar, so 4x the space vs x"deadbeef"?
On Thursday, 8 February 2018 at 18:49:51 UTC, Steven
Schveighoffer wrote:
I wonder if it's an issue with how obj2asm prints it out?
Surely, that data array must be contiguous, and they must be
bytes. Otherwise the resulting code would be wrong.
OK. I didn't even know about obj2asm until you
On 2/8/18 1:42 PM, Ralph Doncaster wrote:
On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote:
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of the
hexStringImpl function, and from the template parameter (the symbol
On 2/8/18 1:25 PM, Walter Bright wrote:
On 2/8/2018 7:07 AM, Steven Schveighoffer wrote:
My concern in the hexString case is the sheer requirement of CTFE for
something that is so easy to do in the compiler, already *done* in the
compiler, and has another form specifically for hex strings (the
On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote:
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of
the hexStringImpl function, and from the template parameter
(the symbol
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of the hexStringImpl
function, and from the template parameter (the symbol
_D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as well,
which will always be larger than
On 2/8/2018 7:07 AM, Steven Schveighoffer wrote:
My concern in the hexString case is the sheer requirement of CTFE for something
that is so easy to do in the compiler, already *done* in the compiler, and has
another form specifically for hex strings (the "\xde\xad\xbe\xef" form) that
isn't
On Thursday, 8 February 2018 at 17:06:55 UTC, H. S. Teoh wrote:
On Thu, Feb 08, 2018 at 08:26:03AM -0500, Steven Schveighoffer
via Digitalmars-d wrote: [...]
The extra data in the object file comes from the inclusion of
the hexStringImpl function, and from the template parameter
(the symbol
On Thu, Feb 08, 2018 at 08:26:03AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> The extra data in the object file comes from the inclusion of the
> hexStringImpl function, and from the template parameter (the symbol
> _D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in
On 2/8/18 9:44 AM, Adam D. Ruppe wrote:
On Thursday, 8 February 2018 at 13:06:44 UTC, Steven Schveighoffer wrote:
So you think it should go into druntime? I don't see why it wasn't in
there in the first place to be honest.
Yeah, probably. I might even publically import it when you import the
On Thursday, 8 February 2018 at 13:06:44 UTC, Steven
Schveighoffer wrote:
So you think it should go into druntime? I don't see why it
wasn't in there in the first place to be honest.
Yeah, probably. I might even publically import it when you import
the posix header so it just works in the
On Thursday, 8 February 2018 at 10:52:35 UTC, Kagamin wrote:
Or have a function specifically for unix permissions, like
int unix(int r, int w, int x, int gr, int gw, int gx, int ur,
int uw, int ux);
It might be even more readable.
I actually personally prefer binary: 0b_1_111_101_000 which
On 2/8/18 1:10 AM, Walter Bright wrote:
On 2/7/2018 9:45 PM, Ralph Doncaster wrote:
> While the fix is a huge improvement, it doesn't match the code
generated by the hex literals. hexString!"deadbeef" stores the
null-terminated string in the data section of the object file, while
On 2/7/18 3:24 PM, Adam D. Ruppe wrote:
On Wednesday, 7 February 2018 at 18:59:38 UTC, Steven Schveighoffer wrote:
Not even close. Octal literals are a disaster, because putting a
leading 0 should never change the base of a number.
I agree the leading 0 is terrible. But that's not the real
Or have a function specifically for unix permissions, like
int unix(int r, int w, int x, int gr, int gw, int gx, int ur, int
uw, int ux);
It might be even more readable.
On Wednesday, 7 February 2018 at 17:01:54 UTC, Adam D. Ruppe
wrote:
http://dpldocs.info/experimental-docs/source/core.sys.posix.fcntl.d.html#L123
version (X86)
{
enum O_CREAT= 0x40; // octal 0100
enum O_EXCL = 0x80; // octal 0200
On 2/7/2018 9:45 PM, Ralph Doncaster wrote:
> While the fix is a huge improvement, it doesn't match the code generated by
the hex literals. hexString!"deadbeef" stores the null-terminated string in the
data section of the object file, while x"deadbeef" only stores 4 bytes in the
data section.
On Thursday, 8 February 2018 at 01:53:43 UTC, Walter Bright wrote:
On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
I just did a quick check, and with DMD v2.078.1, the hexString
template increases code size by ~300 bytes vs the hex literal.
So yet one more reason to prefer the hex literals.
On Thursday, 8 February 2018 at 01:27:46 UTC, Seb wrote:
On Thursday, 8 February 2018 at 00:55:28 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
[...]
They are deprecated:
On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:
On 2/7/2018 8:03 AM, Ralph Doncaster wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.
When I tried it:
import std.conv;
void
On 2/7/2018 6:39 PM, Adam D. Ruppe wrote:
On Thursday, 8 February 2018 at 01:55:19 UTC, Walter Bright wrote:
No, because their usage by druntime is nearly nonexistent.
Only because they're not supported!
Code like `0xsomething // octal something else` is found a whopping 200 times in
On 2/7/2018 6:39 PM, H. S. Teoh wrote:
and hope to make a PR forit shortly.
https://issues.dlang.org/show_bug.cgi?id=18397
The bug report didn't explain what exactly in the implementation wasn't
done right. :-/
The PR does.
https://github.com/dlang/phobos/pull/6138
Another data
On Wed, Feb 07, 2018 at 05:53:43PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
> > I just did a quick check, and with DMD v2.078.1, the hexString
> > template increases code size by ~300 bytes vs the hex literal. So
> > yet one more reason to prefer
On Thu, Feb 08, 2018 at 02:39:50AM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Thursday, 8 February 2018 at 01:55:19 UTC, Walter Bright wrote:
> > No, because their usage by druntime is nearly nonexistent.
>
> Only because they're not supported!
>
> Code like `0xsomething // octal
On Thursday, 8 February 2018 at 01:55:19 UTC, Walter Bright wrote:
No, because their usage by druntime is nearly nonexistent.
Only because they're not supported!
Code like `0xsomething // octal something else` is found a
whopping 200 times in druntime (granted btw all in the core.sys
On 2/7/2018 4:25 PM, H. S. Teoh wrote:
Should templates like octal and hexString be in druntime instead?
No, because their usage by druntime is nearly nonexistent.
On 2/7/2018 5:03 PM, Seb wrote:
On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:
On 2/7/2018 8:03 AM, Ralph Doncaster wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.
When I tried
On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
I just did a quick check, and with DMD v2.078.1, the hexString template
increases code size by ~300 bytes vs the hex literal. So yet one more reason to
prefer the hex literals.
Indeed it does, and that is the result of a poor implementation of
On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:
dmd -c -betterC test2.d
Don't use -c with -betterC when doing tests. The majority of
troubles we have are likely to be linker errors (undefined
references to missing runtime) and that silences them.
On Thursday, 8 February 2018 at 00:55:28 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
[...]
They are deprecated:
https://dlang.org/changelog/pending.html#hexstrings
On Thursday, 8 February 2018 at 00:25:21 UTC, H. S. Teoh wrote:
hexString is in Phobos, and druntime can't use Phobos.
Should templates like octal and hexString be in druntime
instead?
IMO, no. I think the interdependencies between the compiler,
druntime, phobos, and even the packages
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven
Schveighoffer wrote:
They are deprecated:
https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals
Wow, that's... a little superfluous.
I agree with the notion that the language should be
On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:
On 2/7/2018 8:03 AM, Ralph Doncaster wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.
When I tried it:
import std.conv;
void
On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
On 2/7/18 9:59 AM, Ralph Doncaster wrote:
[...]
Good catch! Even the grammar says nothing about what it is,
except it has HexString as a possible literal.
On 2/7/2018 4:08 PM, Mike Franklin wrote:
Don't search for "[betterC]". Instead, use "betterC" (without the brackets).
https://issues.dlang.org/buglist.cgi?quicksearch=betterc_id=219390
We can't reliably rely on informal conventions.
I used the wrong URL. This is the right one (a keyword
On Wed, Feb 07, 2018 at 04:11:19PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/7/2018 12:13 PM, Adam D. Ruppe wrote:
> > even that minor hassle has hurt the use in practice, like in the
> > druntime examples.
>
> hexString is in Phobos, and druntime can't use Phobos.
Should templates
On 2/7/2018 8:03 AM, Ralph Doncaster wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.
When I tried it:
import std.conv;
void test() {
auto data = cast(ubyte[]) hexString!"deadbeef";
}
On 2/7/2018 12:13 PM, Adam D. Ruppe wrote:
even that minor hassle has hurt the use in practice, like in the druntime
examples.
hexString is in Phobos, and druntime can't use Phobos.
On Wednesday, 7 February 2018 at 23:30:57 UTC, Walter Bright
wrote:
Can you please provide a list of these issues, and file issues
that aren't on bugzilla yet, and tag them with the betterC
keyword?
I see only one:
https://issues.dlang.org/buglist.cgi?quicksearch=%5Bbetterc%5D_id=219382
On 2/7/2018 8:05 AM, Adam D. Ruppe wrote:
That's just because -betterC is buggy and extremely incomplete
Can you please provide a list of these issues, and file issues that aren't on
bugzilla yet, and tag them with the betterC keyword?
I see only one:
On Wednesday, 7 February 2018 at 18:59:38 UTC, Steven
Schveighoffer wrote:
Not even close. Octal literals are a disaster, because putting
a leading 0 should never change the base of a number.
I agree the leading 0 is terrible. But that's not the real
question here: it is 0o100 vs import
On Wed, Feb 07, 2018 at 07:29:10PM +, Ralph Doncaster via Digitalmars-d
wrote:
[...]
> I just did a quick check, and with DMD v2.078.1, the hexString
> template increases code size by ~300 bytes vs the hex literal. So yet
> one more reason to prefer the hex literals.
Arguably, this is a QoI
On Wednesday, 7 February 2018 at 19:38:35 UTC, Ali Çehreli wrote:
It sounds so natural. I forgot; what was the argument against
it?
0o was denied basically just because we felt it wasn't necessary
to have in the language at all; that it was rare enough and the
library *can* do it, so the
On Wednesday, 7 February 2018 at 17:36:56 UTC, Seb wrote:
Octal predates GitHub, hexString is new:
Yes, I know, I was there :)
Heck, in the hexString forum thread, I argued that people knowing
this pattern is really useful because then they can do all kinds
of custom literals like stripping
On 02/07/2018 09:01 AM, Adam D. Ruppe wrote:
> But for octal? It was a mistake. We should have just made it 0o.
It sounds so natural. I forgot; what was the argument against it?
Ali
On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven
Schveighoffer wrote:
Seems like the same code you would need to parse the first is
reusable for the second, no? I don't see why this deprecation
was necessary, and now we have more
On Wednesday, 7 February 2018 at 19:25:37 UTC, Ralph Doncaster
wrote:
On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven
Schveighoffer wrote:
Seems like the same code you would need to parse the first is
reusable for the second, no?
On 2/7/18 12:01 PM, Adam D. Ruppe wrote:
On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
For the same reason why octal literals have been deprecated years ago:
https://dlang.org/deprecate.html#Octal%20literals
Not even close. Octal literals are a disaster, because putting a leading
On Wednesday, 7 February 2018 at 17:01:54 UTC, Adam D. Ruppe
wrote:
The octal library solution is brilliant. The genius who wrote
that code is clearly god-like and we should all fall to our
knees and worship his superior intellect. That pattern DOES
have uses.
Octal predates GitHub,
On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
For the same reason why octal literals have been deprecated
years ago:
https://dlang.org/deprecate.html#Octal%20literals
The library solution works as well and it's one of the features
that are rarely used and add up to the steep
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven
Schveighoffer wrote:
On 2/7/18 10:41 AM, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
On 2/7/18 9:59 AM, Ralph Doncaster wrote:
It is mentioned in the literals section, but not documented:
On Wednesday, 7 February 2018 at 16:03:17 UTC, Ralph Doncaster
wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.
That's just because -betterC is buggy and extremely incomplete
(this is why I'm so
On 2/7/18 10:41 AM, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven Schveighoffer wrote:
On 2/7/18 9:59 AM, Ralph Doncaster wrote:
It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals
From reading forum posts I managed
On Wednesday, 7 February 2018 at 15:54:05 UTC, Ralph Doncaster
wrote:
Doesn't that go against the idea of -betterC, or will std.conv
work with -betterC.
p.s. contrary to what the deprecation notice says, hex strings
are very often used in crypto/hashing test cases. Most hash
specs have
On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
On 2/7/18 9:59 AM, Ralph Doncaster wrote:
It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals
From
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
On 2/7/18 9:59 AM, Ralph Doncaster wrote:
It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals
From reading forum posts I managed to figure out that
HexStrings
On 2/7/18 9:59 AM, Ralph Doncaster wrote:
It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals
From reading forum posts I managed to figure out that HexStrings are
prefixed with an x. i.e. x"deadbeef"
Good catch! Even the grammar
It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals
From reading forum posts I managed to figure out that HexStrings
are prefixed with an x. i.e. x"deadbeef"
62 matches
Mail list logo
