Re: Convert wchar* to wstring?

2016-04-04 Thread tcak via Digitalmars-d-learn

On Tuesday, 5 April 2016 at 01:21:55 UTC, Thalamus wrote:
I'm sorry for this total newbie question, but for some reason 
this is eluding me. I must be overlooking something obvious, 
but I haven't been able to figure this out and haven't found 
anything helpful.


I am invoking an entry point in a D DLL from C# (via extern 
(C)), and one of the parameters is a string. This works just 
fine for ANSI, but I'm having trouble with the Unicode 
equivalent.


For ANSI, the message parameter is char*, and string info = 
to!string(message) produces the correct string.


For Unicode, I assumed this would be wchar_t*, as it is in C++. 
(In C++ you can just pass the wchar_t* value to the wstring 
constructor.) So I tried wchar_t*, wchar* and dchar* as well. 
When the message parameter is wchar*, wstring info = 
to!wstring(message) populates the string with the _address_ of 
the wchar*. So when message was in the debugger as 
0x035370e8 L"Writing Exhaustive unit tests is 
exhausting.", the wstring info variable ended up as {length=7 
ptr=0x1c174a20 L"35370E8" }. The dstring*/wchar_t* 
version had equivalent results.


Again, I'm sure I'm missing something obvious, but I poked at 
this problem with various types, casts, Phobos library string 
conversions, and I'm just stumped! :)


thanks,
Thalamus


I cannot give you any code example, but can you try that:

1. By using a loop, calculate the total byte length until finding 
0 (zero). (This would work only if it was given as 
NULL-terminated, otherwise you need to know the length already.)

2. Then define wchar[ calculated_length ] mystring;
3. Copy the content from wchar* into you array. mystring[0 .. 
calculated_length ] = wcharptr[0 .. calculated_length];
4. If you want, you can do casting for your mystring to convert 
it to wstring.


Re: Possible bug in RVO?

2016-04-04 Thread Yuxuan Shui via Digitalmars-d-learn

On Monday, 4 April 2016 at 21:31:08 UTC, Ali Çehreli wrote:

On 04/04/2016 09:36 AM, Anonymouse wrote:

On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote:

[...]

assert(x.aa.length > 0);  // <-- boom

[...]


No idea myself but that's where it seems to go wrong.


Looks like a bug. Just to make it more visible:

auto clobber(ref Set x, ref Set o) {
writefln("entered clobber- x.aa: %s", x.aa);
Set ret;
writefln("did not touch x.aa - x.aa: %s", x.aa);
ret.aa = x.aa;
return ret;
}

x.aa changes during the second call:

entered clobber- x.aa: [1:true]
did not touch x.aa - x.aa: [1:true]
entered clobber- x.aa: [1:true]
did not touch x.aa - x.aa: []  <-- What happened?

Ali


I filed an bug report here: 
https://issues.dlang.org/show_bug.cgi?id=15869


Re: unicode confusion--An answer

2016-04-04 Thread Charles Hixson via Digitalmars-d-learn
I was writing my output to two different files.  Only one of them was 
set to utf-8, the other must have been some other encoding, because when 
I set the encoding to utf-8 everything cleared up.


On 04/04/2016 04:04 PM, Charles Hixson via Digitalmars-d-learn wrote:
Well, at least I think that it's unicode confusion.  When a store 
values into a string (in an array of structs) and then compare it 
against itself, it compares fine, and if I write it out at that point 
it writes out fine.  And validate says it's good unicode.


But later...
valid = true, len = 17, wrd = true , cnt = 2, txt = Gesammtabentheuer
valid = true, len = 27, wrd = true , cnt = 1, txt = 
νεφεληγερέτης

valid = true, len = 17, wrd = true , cnt = 1, txt = ζητοῦσιν
valid = true, len = 36, wrd = true , cnt = 1, txt = 
αἱμορροϊδοκαύστης
valid = true, len = 18, wrd = true , cnt = 2, txt = 
δυνηθώμεν
valid = true, len = 20, wrd = true , cnt = 1, txt = 
προσκρούσω
valid = true, len = 20, wrd = true , cnt = 1, txt = 
σκοτωμένην
valid = true, len = 18, wrd = true , cnt = 1, txt = 
ἀγαπητοί
valid = true, len = 28, wrd = true , cnt = 1, txt = 
הַֽמְזִמָּתָהּ
valid = true, len = 19, wrd = true , cnt = 1, txt = 
Τυρρηνικά

valid = true, len = 17, wrd = true , cnt = 2, txt = IODOHYDRARGYRATIS
valid = true, len = 21, wrd = true , cnt = 1, txt = 
χοινικίσιν

valid = true, len = 17, wrd = true , cnt = 1, txt = Spectrophotometer
valid = true, len = 26, wrd = true , cnt = 1, txt = 
αἰνιττόμενοι
valid = true, len = 70, wrd = 
true , cnt = 1, txt = ΓΗΣΠ
ΛΕΘΡΑΔΙΣΧΙΛΙΑΕΡΓΑΣΙΜΟΥΑΠΟΤΗΣΟΜΟ
valid = true, len = 18, wrd = true , cnt = 1, txt = 
μικρότατα
valid = true, len = 23, wrd = true , cnt = 1, txt = 
ἀποπάτησίν
valid = true, len = 18, wrd = true , cnt = 1, txt = 
מוֹקְשֵׁי

valid = true, len = 17, wrd = true , cnt = 1, txt = διαμένων
 . . . (etc. for 39599 lines)
(And it looks worse than that, actually, because control characters 
aren't coming through).
I think the originals were usually greek letters due to an earlier 
test (why there should be so many greek words I don't know...but if 
they're there I want them to be handled properly), but the corrupted 
text is such a small part of the original file that I can't be 
certain.  Valid = true means that it passed string validates right 
before being printed.  wrd = true means that the only characters in it 
should be isAlpha, hyphen, apostrophe, or underscore.  cnt = n means 
that it was detected n times in the dataset (of 8013 text files). And 
the string in each struct is only written once in the execution of the 
program.


I was scanning the dataset looking to see what long words were 
valid...I didn't expect THIS at all.  And as you can see from, e.g., 
"Spectrophotometer", ASCII values don't seem to be damaged at all.


FWIW, I was expecting to encounter an occasional Greek, French, or 
Chinese word...but nothing like this.  I'd think it was the conversion 
from string to dchar[] and back that was the problem, but when I test 
immediately after I know I've written to the string everything looks 
right.  So I'm guessing it's something about how unicode is handled.






Re: Decompressing bzip2

2016-04-04 Thread Mike Parker via Digitalmars-d-learn

On Monday, 4 April 2016 at 21:32:10 UTC, stunaep wrote:


Can you please explain what the scope keyword does and if there


scope was originally intended to be used primarily with classes 
in order to get deterministic destruction. It ensures the 
destructor of a class is called when the scope exits, just as 
with a struct. It's not needed here and shouldn't really be used 
at all anymore. It has been superseded by std.typecons.scoped 
[1]. It's not needed here at all, though. bz_stream is a struct, 
so there's no need to allocate an instance of it:


bz_stream stream;

Then you can just take its address when passing it to functions:

int init_error = BZ2_bzDecompressInit(, 0, 0);


is any benefit to using
"new byte[](size)" over "new byte[size]" with a 1D array?


This is the newer and recommended syntax for allocating arrays. 
The idea is that it helps improve readability because the old 
syntax, "new byte[size]", brings to mind static array 
declarations, and that it's consistent with the syntax for 
allocating other types:


new T(arg);

[1] https://dlang.org/phobos/std_typecons.html#.scoped


unicode confusion

2016-04-04 Thread Charles Hixson via Digitalmars-d-learn
Well, at least I think that it's unicode confusion.  When a store values 
into a string (in an array of structs) and then compare it against 
itself, it compares fine, and if I write it out at that point it writes 
out fine.  And validate says it's good unicode.


But later...
valid = true, len = 17, wrd = true , cnt = 2, txt = Gesammtabentheuer
valid = true, len = 27, wrd = true , cnt = 1, txt = 
νεφεληγερέτης

valid = true, len = 17, wrd = true , cnt = 1, txt = ζητοῦσιν
valid = true, len = 36, wrd = true , cnt = 1, txt = 
αἱμορροϊδοκαύστης

valid = true, len = 18, wrd = true , cnt = 2, txt = δυνηθώμεν
valid = true, len = 20, wrd = true , cnt = 1, txt = προσκρούσω
valid = true, len = 20, wrd = true , cnt = 1, txt = σκοτωμένην
valid = true, len = 18, wrd = true , cnt = 1, txt = ἀγαπητοί
valid = true, len = 28, wrd = true , cnt = 1, txt = 
הַֽמְזִמָּתָהּ

valid = true, len = 19, wrd = true , cnt = 1, txt = Τυρρηνικά
valid = true, len = 17, wrd = true , cnt = 2, txt = IODOHYDRARGYRATIS
valid = true, len = 21, wrd = true , cnt = 1, txt = 
χοινικίσιν

valid = true, len = 17, wrd = true , cnt = 1, txt = Spectrophotometer
valid = true, len = 26, wrd = true , cnt = 1, txt = 
αἰνιττόμενοι
valid = true, len = 70, 
wrd = true , cnt = 
1, txt = 
ΓΗΣΠΛΕΘΡΑΔΙΣΧΙΛΙΑΕΡΓΑΣΙΜΟΥΑΠΟΤΗΣΟΜΟ

valid = true, len = 18, wrd = true , cnt = 1, txt = μικρότατα
valid = true, len = 23, wrd = true , cnt = 1, txt = 
ἀποπάτησίν

valid = true, len = 18, wrd = true , cnt = 1, txt = מוֹקְשֵׁי
valid = true, len = 17, wrd = true , cnt = 1, txt = διαμένων
 . . . (etc. for 39599 lines)
(And it looks worse than that, actually, because control characters 
aren't coming through).
I think the originals were usually greek letters due to an earlier test 
(why there should be so many greek words I don't know...but if they're 
there I want them to be handled properly), but the corrupted text is 
such a small part of the original file that I can't be certain.  Valid = 
true means that it passed string validates right before being printed.  
wrd = true means that the only characters in it should be isAlpha, 
hyphen, apostrophe, or underscore.  cnt = n means that it was detected n 
times in the dataset (of 8013 text files). And the string in each struct 
is only written once in the execution of the program.


I was scanning the dataset looking to see what long words were valid...I 
didn't expect THIS at all.  And as you can see from, e.g., 
"Spectrophotometer", ASCII values don't seem to be damaged at all.


FWIW, I was expecting to encounter an occasional Greek, French, or 
Chinese word...but nothing like this.  I'd think it was the conversion 
from string to dchar[] and back that was the problem, but when I test 
immediately after I know I've written to the string everything looks 
right.  So I'm guessing it's something about how unicode is handled.


Re: Where do I learn to use GtkD

2016-04-04 Thread Mike Wey via Digitalmars-d-learn

On 04/04/2016 09:33 PM, Karabuta wrote:

On Monday, 14 March 2016 at 03:46:02 UTC, Gerald wrote:

On Sunday, 13 March 2016 at 19:53:35 UTC, karabuta wrote:

On Sunday, 13 March 2016 at 19:34:36 UTC, WebFreak001 wrote:

and in the (not quite complete) documentation you can find widgets
you might want to use. Its a great place for getting ideas on which
widgets to use imo. http://api.gtkd.org/src/gtk/AboutDialog.html


That thing really need some work to make it consumable :)


I contributed a script (makeddocs.sh) to generate the documentation in
ddox instead of candydocs, ddox is miles better then candydocs and
using it is way more efficient IMHO.


Where can I find and use?


https://github.com/gtkd-developers/GtkD/blob/master/makeddox.sh

running ./makedocs.sh should generate the ddox documentation.

--
Mike Wey


Re: Decompressing bzip2

2016-04-04 Thread stunaep via Digitalmars-d-learn

On Monday, 4 April 2016 at 08:26:07 UTC, Thomas Brix Larsen wrote:

On Sunday, 3 April 2016 at 02:03:29 UTC, stunaep wrote:
I am trying to use the bzip2 bindings that are available on 
code.dlang.org/packages, but I am having a really hard time 
using it due to the pointers. It needs to be an array once 
it's decompressed.


Here is what I have:

import std.stdio;
import bzlib;

void main(string[] args)
{

   File f = File("./test.bz2");
   ubyte[] data = new ubyte[f.size];
  f.rawRead(data);
   writeln(data);

   ubyte* output;
   uint avail_out;
   bz_stream* stream = new bz_stream();
   stream.avail_out = avail_out;
   stream.next_out = output;

   int init_error = BZ2_bzDecompressInit(stream, 0, 0);
   int bzipresult = BZ2_bzDecompress(stream);

   stream.avail_in = cast(uint) data.length;
   stream.next_in = cast(ubyte*) data;

   bzipresult = BZ2_bzDecompress(stream);
   int read = stream.total_out_lo32;
   BZ2_bzDecompressEnd(stream);
   delete stream;
   writeln(output);
}


It's not working at all so any help would be very much 
appreciated.


You need to allocate the output array:

import std.stdio;
import bzlib;

void main(string[] args)
{
File f = File("./test.bz2");
auto data = new ubyte[](f.size);
f.rawRead(data);
writeln(data);

auto output = new ubyte[](4096);
scope stream = new bz_stream();
stream.avail_out = cast(uint)output.length;
stream.next_out = output.ptr;

int init_error = BZ2_bzDecompressInit(stream, 0, 0);
int bzipresult = BZ2_bzDecompress(stream);

stream.avail_in = cast(uint)data.length;
stream.next_in = data.ptr;

bzipresult = BZ2_bzDecompress(stream);
int read = stream.total_out_lo32;
BZ2_bzDecompressEnd(stream);
writeln(output);
}


Can you please explain what the scope keyword does and if there 
is any benefit to using

"new byte[](size)" over "new byte[size]" with a 1D array?


Re: Possible bug in RVO?

2016-04-04 Thread Ali Çehreli via Digitalmars-d-learn

On 04/04/2016 09:36 AM, Anonymouse wrote:

On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote:

On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote:
auto clobber(ref Set x, ref Set o) {
Set ret;
ret.aa = x.aa;

assert(x.aa.length > 0);  // <-- boom

return ret;
}


No idea myself but that's where it seems to go wrong.


Looks like a bug. Just to make it more visible:

auto clobber(ref Set x, ref Set o) {
writefln("entered clobber- x.aa: %s", x.aa);
Set ret;
writefln("did not touch x.aa - x.aa: %s", x.aa);
ret.aa = x.aa;
return ret;
}

x.aa changes during the second call:

entered clobber- x.aa: [1:true]
did not touch x.aa - x.aa: [1:true]
entered clobber- x.aa: [1:true]
did not touch x.aa - x.aa: []  <-- What happened?

Ali



Re: Catching thread creation error

2016-04-04 Thread tcak via Digitalmars-d-learn

On Monday, 4 April 2016 at 20:28:13 UTC, tcak wrote:
In my server program, when a request comes, I create a new 
thread for that.


I put memory limit to program with setrlimit. So, when the 
limit is reached, new thread cannot be created.


I want to tell client back that there is system problem. But 
catching "Throwable" does not suffice for this it seems like. 
Program still breaks and tells that "Error creating thread". Is 
there any normal way to catch this event?


Okay. That's my mistake. I was looking at "new Thread" part 
instead of "start". The "start" function is what allocates memory 
for the new thread. So, it is the one where try-catch should be 
used.


Catching thread creation error

2016-04-04 Thread tcak via Digitalmars-d-learn
In my server program, when a request comes, I create a new thread 
for that.


I put memory limit to program with setrlimit. So, when the limit 
is reached, new thread cannot be created.


I want to tell client back that there is system problem. But 
catching "Throwable" does not suffice for this it seems like. 
Program still breaks and tells that "Error creating thread". Is 
there any normal way to catch this event?


Re: Where do I learn to use GtkD

2016-04-04 Thread Karabuta via Digitalmars-d-learn

On Monday, 14 March 2016 at 03:46:02 UTC, Gerald wrote:

On Sunday, 13 March 2016 at 19:53:35 UTC, karabuta wrote:

On Sunday, 13 March 2016 at 19:34:36 UTC, WebFreak001 wrote:
and in the (not quite complete) documentation you can find 
widgets you might want to use. Its a great place for getting 
ideas on which widgets to use imo. 
http://api.gtkd.org/src/gtk/AboutDialog.html


That thing really need some work to make it consumable :)


I contributed a script (makeddocs.sh) to generate the 
documentation in ddox instead of candydocs, ddox is miles 
better then candydocs and using it is way more efficient IMHO.


Where can I find and use?


Re: Possible bug in RVO?

2016-04-04 Thread Anonymouse via Digitalmars-d-learn

On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote:

On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote:
auto clobber(ref Set x, ref Set o) {
Set ret;
ret.aa = x.aa;

  assert(x.aa.length > 0);  // <-- boom

return ret;
}


No idea myself but that's where it seems to go wrong.


Re: Read only delegate

2016-04-04 Thread Edwin van Leeuwen via Digitalmars-d-learn

On Monday, 4 April 2016 at 11:39:55 UTC, Kagamin wrote:

On Monday, 4 April 2016 at 11:32:23 UTC, Rene Zwanenburg wrote:

https://issues.dlang.org/show_bug.cgi?id=1983


Bug 1983 is about usage of delegates after creation, 
restrictions during creation are enforced. AIU, OP wants to 
have const check during creation.


I think the underlying issue is the same. The problem seems to be 
that:
Unfortunately, there is no way to declare a const delegate (by 
which I mean, a delegate whose context pointer is typed const).


I actually discovered the problem, due to the hole it leaves in 
the const system, where I got different results calling a const 
method multiple times. The const method in question called a 
delegate that changed its context pointer, resulting in changes 
during calls.




Re: No aa.byKey.length?

2016-04-04 Thread John Colvin via Digitalmars-d-learn

On Monday, 4 April 2016 at 02:32:56 UTC, Yuxuan Shui wrote:

On Monday, 4 April 2016 at 00:50:27 UTC, Jonathan M Davis wrote:
On Sunday, April 03, 2016 23:46:10 John Colvin via 
Digitalmars-d-learn wrote:
On Saturday, 2 April 2016 at 16:00:51 UTC, Jonathan M Davis 
wrote:

> [...]

Maybe

aa.byKey().takeExactly(aa.length)


Yeah, that's a clever workaround.

- Jonathan M Davis


So should we not add length to byKey?


Yes. But until that happens, my workaround allows you to carry on 
getting work done :)


Re: Read only delegate

2016-04-04 Thread Edwin van Leeuwen via Digitalmars-d-learn

On Monday, 4 April 2016 at 11:32:23 UTC, Rene Zwanenburg wrote:
On Monday, 4 April 2016 at 08:10:10 UTC, Edwin van Leeuwen 
wrote:
Is there a way to make sure a delegate only reads state, 
without changing it? I tried annotating the delegate as const, 
but that does not seem to work.

```


Yeah this is a nasty old issue. The underlying problem is that 
a delegate's function and context pointers are completely 
untyped.


https://issues.dlang.org/show_bug.cgi?id=1983


Thanks for the reference, hopefully this will be resolved at some 
point :)




Re: Read only delegate

2016-04-04 Thread Kagamin via Digitalmars-d-learn

On Monday, 4 April 2016 at 11:32:23 UTC, Rene Zwanenburg wrote:

https://issues.dlang.org/show_bug.cgi?id=1983


Bug 1983 is about usage of delegates after creation, restrictions 
during creation are enforced. AIU, OP wants to have const check 
during creation.


Re: Read only delegate

2016-04-04 Thread Rene Zwanenburg via Digitalmars-d-learn

On Monday, 4 April 2016 at 08:10:10 UTC, Edwin van Leeuwen wrote:
Is there a way to make sure a delegate only reads state, 
without changing it? I tried annotating the delegate as const, 
but that does not seem to work.

```


Yeah this is a nasty old issue. The underlying problem is that a 
delegate's function and context pointers are completely untyped.


https://issues.dlang.org/show_bug.cgi?id=1983


Re: Read only delegate

2016-04-04 Thread Edwin van Leeuwen via Digitalmars-d-learn

On Monday, 4 April 2016 at 08:10:10 UTC, Edwin van Leeuwen wrote:
Is there a way to make sure a delegate only reads state, 
without changing it? I tried annotating the delegate as const, 
but that does not seem to work.




Note that annotating with pure also doesn't help. As a result we 
can have a pure delegate that returns different results every 
time it is called.


```D
void main()
{
import std.stdio : writeln;
auto r = [0,1,2,3];

auto f = delegate() const pure
{
import std.array : front, popFront;
r.popFront;
return r.front;
};

r.writeln; // [0,1,2,3]
auto f1 = f();
r.writeln; // [1,2,3]
assert( f() == f1 ); // Throws
}
```



Re: No aa.byKey.length?

2016-04-04 Thread Jonathan M Davis via Digitalmars-d-learn
On Monday, April 04, 2016 02:32:56 Yuxuan Shui via Digitalmars-d-learn wrote:
> On Monday, 4 April 2016 at 00:50:27 UTC, Jonathan M Davis wrote:
> > On Sunday, April 03, 2016 23:46:10 John Colvin via
> >
> > Digitalmars-d-learn wrote:
> >> On Saturday, 2 April 2016 at 16:00:51 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > [...]
> >>
> >> Maybe
> >>
> >> aa.byKey().takeExactly(aa.length)
> >
> > Yeah, that's a clever workaround.
>
> So should we not add length to byKey?

I don't see any reason for the result of byKey to not have length. It's just
that given that it doesn't currently have length, John's suggestion provides
a way to turn it into a range with length.

- Jonathan M Davis


Re: Decompressing bzip2

2016-04-04 Thread Thomas Brix Larsen via Digitalmars-d-learn

On Sunday, 3 April 2016 at 02:03:29 UTC, stunaep wrote:
I am trying to use the bzip2 bindings that are available on 
code.dlang.org/packages, but I am having a really hard time 
using it due to the pointers. It needs to be an array once it's 
decompressed.


Here is what I have:

import std.stdio;
import bzlib;

void main(string[] args)
{

   File f = File("./test.bz2");
   ubyte[] data = new ubyte[f.size];
  f.rawRead(data);
   writeln(data);

   ubyte* output;
   uint avail_out;
   bz_stream* stream = new bz_stream();
   stream.avail_out = avail_out;
   stream.next_out = output;

   int init_error = BZ2_bzDecompressInit(stream, 0, 0);
   int bzipresult = BZ2_bzDecompress(stream);

   stream.avail_in = cast(uint) data.length;
   stream.next_in = cast(ubyte*) data;

   bzipresult = BZ2_bzDecompress(stream);
   int read = stream.total_out_lo32;
   BZ2_bzDecompressEnd(stream);
   delete stream;
   writeln(output);
}


It's not working at all so any help would be very much 
appreciated.


You need to allocate the output array:

import std.stdio;
import bzlib;

void main(string[] args)
{
File f = File("./test.bz2");
auto data = new ubyte[](f.size);
f.rawRead(data);
writeln(data);

auto output = new ubyte[](4096);
scope stream = new bz_stream();
stream.avail_out = cast(uint)output.length;
stream.next_out = output.ptr;

int init_error = BZ2_bzDecompressInit(stream, 0, 0);
int bzipresult = BZ2_bzDecompress(stream);

stream.avail_in = cast(uint)data.length;
stream.next_in = data.ptr;

bzipresult = BZ2_bzDecompress(stream);
int read = stream.total_out_lo32;
BZ2_bzDecompressEnd(stream);
writeln(output);
}


Read only delegate

2016-04-04 Thread Edwin van Leeuwen via Digitalmars-d-learn
Is there a way to make sure a delegate only reads state, without 
changing it? I tried annotating the delegate as const, but that 
does not seem to work.


```D
void main()
{
import std.stdio : writeln;
auto r = [0,1,2,3];

auto f = delegate() const // Compiles even though we are 
changing r

{
import std.array : popFront;
r.popFront;
};

r.writeln; // [0,1,2,3]
f();
r.writeln; // [1,2,3]
}
```




Re: Shouldn't the following code produce a warning?

2016-04-04 Thread Jonathan M Davis via Digitalmars-d-learn
On Monday, April 04, 2016 13:23:16 ric maicle via Digitalmars-d-learn wrote:
> The values of the variables here can be determined during compilation.
> Should there be some kind of warning like, unsigned integer may not be
> compared to a value less than zero; or there shouldn't be since the
> programmer should have known what he's doing?

Agruably, it should generate a warning, but it doesn't currently. There are
these two related bug reports / enhancement requests though:

https://issues.dlang.org/show_bug.cgi?id=6949
https://issues.dlang.org/show_bug.cgi?id=259

- Jonathan M Davis