Re: D vs nim

[Stefan Koch via Digitalmars-d]

On Tuesday, 27 March 2018 at 12:02:37 UTC, jmh530 wrote:
On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour 
wrote:

[snip]

I would like to refocus this thread on feature set and how it 
compares to D, not on flame wars about brackets or language 
marketing issues.


In the comparison you made
https://github.com/timotheecour/D_vs_nim/
you say the CTFE engine for nim is a register VM. Stefan Koch's 
new CTFE is a bytecode interpreter. Is there an advantage of 
one over the other?


newCTFE can have different backends, tough the current default is 
a register based vm with a limited number of regs (16384).

Re: unittests, dub and libraries

[Joe via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 03:07:23 UTC, Jonathan M Davis 
wrote:

Run

dub test

The problem is that an executable needs a main, and a library 
doesn't have one, whereas when you're testing a library, you 
need an executable. So, a main must be inserted - e.g. with the 
-main flag to dmd. Just building the unittest build doesn't 
insert one. However, dub test _does_ deal with that for you.


Thanks.

Re: rvalues -> ref (yup... again!)

[Rubn via Digitalmars-d]

On Wednesday, 28 March 2018 at 00:56:29 UTC, kinke wrote:

On Tuesday, 27 March 2018 at 23:59:09 UTC, Rubn wrote:
Just adding a few writeln it isn't able to remove the function 
entirely anymore and can't optimize it out.


Well writeln() here involves number -> string formatting, GC, 
I/O, template bloat... There are indeed superfluous memcpy's in 
your foo() there (although the forward and bar calls are still 
inlined), which after a quick glance seem to be LLVM optimizer 
shortcomings, the IR emitted by LDC looks fine.
For an abitrary external function, it's all fine as it should 
be, boiling down to a single memcpy in foo() and a direct 
memset in main(): https://run.dlang.io/is/O1aeLK


Well somethings wrong if writeln causes optimization to not 
occur, if that is the case then it'd be best to just use printf() 
instead. Anyways using small examples to show optimization is 
usually not what's going to happen in actual code. Functions are 
rarely that simple, and if adding a single writeln() to a call is 
enough to eliminate that optimization, I can only imagine what 
other little things do as well.

[Issue 18669] isNestedFunction does not check if parameter is a function

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18669] isNestedFunction does not check if parameter is a function

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/09cc0bac145422636e88616ce88f8bab3f0adefc
Fix Issue 18669 - isNestedFunction does not check if parameter is a function

https://github.com/dlang/phobos/commit/a6afdef9320f9eb5ccd868928742c274d149a9f1
Merge pull request #6355 from JackStouffer/issue18669

Fix Issue 18669 - isNestedFunction does not check if parameter is a f…
merged-on-behalf-of: Jack Stouffer 

--

Re: unittests, dub and libraries

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, March 28, 2018 02:16:59 Joe via Digitalmars-d-learn wrote:
> I'm trying to build a very simple library. For now it just has a
> single class, constructor, destructor and one method.  I added a
> unit test right after the method, declared the targetType to be
> "library" and a buildType of "unittest" (with options
> "unittests", "debugMode", "debugInfo"). When I run
>
>dub run -b unittest
>
> it builds the library, but then says:
>
>Target is a library. Skipping execution.
>
> If I compile with ldc2 -unittest the linker throws the error:
>
>(.text+0x20): undefined reference to `main'
>
> If I add an empty main function to the source file, ldc2/gcc
> manage to create an executable that can be invoked manually and
> it runs through the unit test.
>
> Is this the best that can be done?

Run

dub test

The problem is that an executable needs a main, and a library doesn't have
one, whereas when you're testing a library, you need an executable. So, a
main must be inserted - e.g. with the -main flag to dmd. Just building the
unittest build doesn't insert one. However, dub test _does_ deal with that
for you.

- Jonathan M Davis

[Issue 18672] Error in @safe transitive propagation with associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

unittests, dub and libraries

[Joe via Digitalmars-d-learn]

I'm trying to build a very simple library. For now it just has a 
single class, constructor, destructor and one method.  I added a 
unit test right after the method, declared the targetType to be 
"library" and a buildType of "unittest" (with options 
"unittests", "debugMode", "debugInfo"). When I run


  dub run -b unittest

it builds the library, but then says:

  Target is a library. Skipping execution.

If I compile with ldc2 -unittest the linker throws the error:

  (.text+0x20): undefined reference to `main'

If I add an empty main function to the source file, ldc2/gcc 
manage to create an executable that can be invoked manually and 
it runs through the unit test.


Is this the best that can be done?

Re: Checking if a structs .init value is zero bits only

[Seb via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 00:15:34 UTC, Per Nordlöw wrote:
Is there a way to check if a struct `S` can be initialized 
using zero bits only, so that we can allocate and initialize an 
array of `S` in one go using `calloc`? If not, what should such 
a trait look like?


Have a look at:

https://github.com/dlang/phobos/pull/6024

(review/feedbackon this PR is welcome!)

[Issue 18197] [REG2.073] Internal error: backend\cgcod.c 1659

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/689fa72cb110250bc8b0dc152e48e20ba1f67cf9
Fix issue 18197 - Correct optimization for OPpair in x87 mode

Attempting to push a non-fp value into mST0 results in a ICE.

https://github.com/dlang/dmd/commit/69ece8ca5b0bcaf290cfcb8a29c44048e9678284
Merge pull request #8082 from LemonBoy/b18197

Fix Issue 18197 - Correct optimization for OPpair in x87 mode
merged-on-behalf-of: Walter Bright 

--

[Issue 18197] [REG2.073] Internal error: backend\cgcod.c 1659

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: rvalues -> ref (yup... again!)

[kinke via Digitalmars-d]

On Tuesday, 27 March 2018 at 23:59:09 UTC, Rubn wrote:
Just adding a few writeln it isn't able to remove the function 
entirely anymore and can't optimize it out.


Well writeln() here involves number -> string formatting, GC, 
I/O, template bloat... There are indeed superfluous memcpy's in 
your foo() there (although the forward and bar calls are still 
inlined), which after a quick glance seem to be LLVM optimizer 
shortcomings, the IR emitted by LDC looks fine.
For an abitrary external function, it's all fine as it should be, 
boiling down to a single memcpy in foo() and a direct memset in 
main(): https://run.dlang.io/is/O1aeLK

Re: Checking if a structs .init value is zero bits only

[Ali Çehreli via Digitalmars-d-learn]

On 03/27/2018 05:15 PM, Per Nordlöw wrote:
Is there a way to check if a struct `S` can be initialized using zero 
bits only, so that we can allocate and initialize an array of `S` in one 
go using `calloc`? If not, what should such a trait look like?


The following idea should work. One question that I'm not certain about 
is whether padding bytes inside .init can ever be non-zero in D. I 
assumed they are always zero. If not, the same idea must be applied 
recursively to individual members.


bool allZeros(T)() {
// Yes, this can be implemented as a range algorithm. :)
T t;
foreach (b; (cast(ubyte*))[0..T.sizeof]) {
if (b) {
return false;
}
}
return true;
}

unittest {
static struct A {
int i;
long l;
}
static struct B {
double d;
}
assert(allZeros!A);
assert(!allZeros!B);
}

void main() {
}

Ali

Checking if a structs .init value is zero bits only

[Per Nordlöw via Digitalmars-d-learn]

Is there a way to check if a struct `S` can be initialized using 
zero bits only, so that we can allocate and initialize an array 
of `S` in one go using `calloc`? If not, what should such a trait 
look like?

Re: rvalues -> ref (yup... again!)

[kinke via Digitalmars-d]

On Tuesday, 27 March 2018 at 23:35:44 UTC, kinke wrote:

On Tuesday, 27 March 2018 at 21:52:25 UTC, Rubn wrote:
It happens with LDC too, not sure how it would be able to know 
to do any kind of optimization like that unless it was able to 
inline every single function called into one function and be 
able to do optimize it from there. I don't imagine that'll be 
likely though.


It does it in your code sample with `-O`, there's no call to 
bar and the foo() by-value arg is memcpy'd to the global.


For reference: https://run.dlang.io/is/2vDEXP
Note that main() boils down to a `memset(, 10, 1024); return 
0;`:


_Dmain:
.cfi_startproc
pushq   %rax
.Lcfi0:
.cfi_def_cfa_offset 16
data16
leaqonlineapp.Foo onlineapp.gfoo@TLSGD(%rip), %rdi
data16
data16
rex64
callq   __tls_get_addr@PLT
movl$10, %esi
movl$1024, %edx
movq%rax, %rdi
callq   memset@PLT
xorl%eax, %eax
popq%rcx
retq

Re: Recursive attribute for virtual functions?

[ag0aep6g via Digitalmars-d]

On 03/28/2018 01:34 AM, arturg wrote:

you can call them with __traits(getOverloads, T, "name")[index];

you can overload on types attributes and linkage, but seems like you can 
only merge overloads based on types.


I don't think there's value in allowing overloads that can only be 
called via __traits.


Looks like this is an old issue [1] that is currently being fixed. 
run.dlang.io's "beta" and "nightly" compilers don't accept such 
overloads [2]. But I can't reproduce that locally. The fix has 
apparently been reverted because it needs more work.



[1] https://issues.dlang.org/show_bug.cgi?id=2789
[2] https://run.dlang.io/is/qlyMti

Re: rvalues -> ref (yup... again!)

[Rubn via Digitalmars-d]

On Tuesday, 27 March 2018 at 23:35:44 UTC, kinke wrote:

On Tuesday, 27 March 2018 at 21:52:25 UTC, Rubn wrote:
It happens with LDC too, not sure how it would be able to know 
to do any kind of optimization like that unless it was able to 
inline every single function called into one function and be 
able to do optimize it from there. I don't imagine that'll be 
likely though.


It does it in your code sample with `-O`, there's no call to 
bar and the foo() by-value arg is memcpy'd to the global.


If you compile everything with LTO, your code and all 3rd-party 
libs as well as druntime/Phobos, LLVM is able to optimize the 
whole program as if it were inside a single gigantic 'object' 
file in LLVM bitcode IR, and is thus indeed theoretically able 
to inline *all* functions.


A bit off topic now but anyways:

Well that example I posted didn't do anything, so it would 
optimize it out quite easily. The entire function was excluded 
essentially. Just adding a few writeln it isn't able to remove 
the function entirely anymore and can't optimize it out. Idk if 
you want to try some different options but flto didn't do 
anything for it.


https://godbolt.org/g/bLdpnm

import std.stdio : writeln;

struct Foo {
ubyte[1024] data;

this(int a)
{
data[0] = cast(ubyte)a;
}
}

void foo(T)(auto ref T t) {
import std.functional: forward;
writeln(gfoo.data[0]);
bar(forward!t);
writeln(gfoo.data[0]);
}

__gshared Foo gfoo;

void bar(T)(auto ref T t) {
import std.algorithm.mutation : move;
writeln(gfoo.data[0]);
move(t, gfoo);
}

void main() {
foo(Foo(10));
}

Re: utf.d codeLength asserts false on certain input

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, March 27, 2018 23:29:57 Anonymouse via Digitalmars-d-learn 
wrote:
> My IRC bot is suddenly seeing crashes. It reads characters from a
> Socket into an ubyte[] array, then idups parts of that (full
> lines) into strings for parsing. Parsing involves slicing such
> strings into meaningful segments; sender, event type, target
> channel/user, message content, etc. I can assume all of them to
> be char[]-compliant except for the content field.
>
> Running it in a debugger I see I'm tripping an assert in utf.d[1]
> when calling stripRight on a content slice[2].
>
> > /++
> >
> > Returns the number of code units that are required to
> >
> > encode the code point
> >
> > $(D c) when $(D C) is the character type used to encode it.
> >
> >   +/
> >
> > ubyte codeLength(C)(dchar c) @safe pure nothrow @nogc
> > if (isSomeChar!C)
> > {
> >
> > static if (C.sizeof == 1)
> > {
> >
> > if (c <= 0x7F) return 1;
> > if (c <= 0x7FF) return 2;
> > if (c <= 0x) return 3;
> > if (c <= 0x10) return 4;
> > assert(false);  // <--
> >
> > }
> > // ...
>
> This trips it:
> > import std.string;
> >
> > void main()
> > {
> >
> > string s = "\355\342\256 \342\245\341⮢\256\245
> >
> > ᮮ\241饭\250\245".stripRight;  // <-- asserts false
> > }
>
> The real backtrace:
> > #0  _D3std3utf__T10codeLengthTaZQpFNaNbNiNfwZh (c=26663461) at
> > /usr/include/dlang/dmd/std/utf.d:2530
> > #1  0x5578d7aa in
> > _D3std6string__T10stripRightTAyaZQrFQhZ14__foreachbody2MFNaNbNiNfKmKwZi
> > (this=0x7fff99c0, __applyArg1=@0x7fff9978: 26663461,
> > __applyArg0=@0x7fff9970: 17) at
> > /usr/include/dlang/dmd/std/string.d:2918 #2  0x77a47014 in
> > _aApplyRcd2 () from
> > /usr/lib/libphobos2.so.0.78
> > #3  0x5578d731 in
> > _D3std6string__T10stripRightTAyaZQrFNaNiNfQnZQq (str=...) at
> > /usr/include/dlang/dmd/std/string.d:2915
> > #4  0x558e0cc7 in
> > _D8kameloso3irc17parseSpecialcasesFNaNfKSQBnQBh9IRCParserKSQCf7ircdefs8I
> > RCEventKAyaZv (slice=..., event=...,parser=...) at
> > source/kameloso/irc.d:1184
> Should that not be an Exception, as it's based on input? I'm not
> sure where the character 26663461 came from. Even so, should it
> assert?
>
> I don't know what to do right now. I'd like to avoid sanitizing
> all lines. I could catch an Exception but not so much an
> AssertError.
>
>
> [1]: https://github.com/dlang/phobos/blob/master/std/utf.d#L2522
> [2]:
> https://github.com/zorael/kameloso/blob/master/source/kameloso/irc.d#L1184

It means that codeLength requires that dchar be a valid code point, though
the documentation doesn't say that. It probably should. It was probably
assumed that no one would try to pass it an invalid code point - especially
since it's usually called with well-known values rather than data from some
place like a socket. Regardless, the way to work around it would be to call
isValidDchar on the dchar before passing it to codeLength so that you can
handle the invalid code point rather than calling codeLength on it.

- Jonathan M Davis

Re: Recursive attribute for virtual functions?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, March 27, 2018 21:10:25 12345swordy via Digitalmars-d wrote:
> On Tuesday, 27 March 2018 at 21:05:32 UTC, ag0aep6g wrote:
> > On 03/27/2018 11:02 PM, 12345swordy wrote:
> >> Then explain this then.
> >> https://run.dlang.io/is/S2KLs5
> >
> > B.talk is @safe. The compiler ignores the @system attribute on
> > B.talk, because A.talk's @safe attribute takes precedence.
>
> Shouldn't it give a warning then?

Warnings are almost always a terrible idea, since it's bad practice to leave
warnings in place, meaning that it's effectively the same as an error except
that it doesn't force folks to fix the problem immediately, and thanks to
-w, it effectively forks the language, because stuff like is expressions and
which template constraints pass or not can change based on whether -w is
used or not. IMHO, it was a huge mistake to ever add warnings to the
compiler. So, if we were going to do something with this, it should be an
error, not a warning.

In most cases, D ignores attributes that don't apply, which is sometimes
annoying, but it can be very handy in generic code. It can also be helpful
when an attribute is applied with : or {}. So, it's not particularly
surprising that the compiler would ignore the attribute in this case. That
being said, at the moment, I can't think of any reason why it would be
beneficial to allow marking a derived function with @system directly when
the base class function is @safe. Marking it with @trusted is often
valuable, because in that case, the derived function is doing something
that's @system, but the programmer has validated that it's @safe, so it
doesn't violate the API of the base class. So, you wouldn't want to treat it
like you would a function that was directly marked with @safe @trusted, but
that doesn't mean that @system couldn't be disallowed.

- Jonathan M Davis

Re: Recursive attribute for virtual functions?

[arturg via Digitalmars-d]

On Tuesday, 27 March 2018 at 23:34:20 UTC, arturg wrote:

On Tuesday, 27 March 2018 at 23:23:38 UTC, ag0aep6g wrote:


DMD might accept that, but I don't think it works in a 
meaningful way. How do you call the @system one?


Looks like the @safe one will always be called, even from 
@system code:



import std.stdio;

void talk() @system { writeln("@system"); }
void talk() @safe { writeln("@safe"); }

void main() @system
{
talk(); /* Prints "@safe". */
}



you can call them with __traits(getOverloads, T, "name")[index];

you can overload on types attributes and linkage, but seems 
like you can only merge overloads based on types.


i have some templates which can be used like this:

type.dgAt!("name", index);
dgAt!("name", index, somemodule);
dgAt!("name", index, "somemodule");
alias fun = aAt!("name", index, someTypeOrModule);

type.dgOf!("name", void function(int)@safe);
dgOf!("name", void function(int)@safe, module);
dgOf!("name", void function(int)@safe, "module");

from!(type, "name").aAt!1;
from!(type, "name").aOf!(void function(int));
from!(type, "name").dgAt!1;
from!(type, "name").dgOf!(void function(int));

but this fails:
type.dgOf!("name", extern(C) void function(int)@safe);

and this works:
alias funtype = extern(C) void function(int)@safe;
type.dgOf!("name", funtype);

[Issue 17874] Segmentation fault when constructing a struct with a static array of structs containing floats

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17874] Segmentation fault when constructing a struct with a static array of structs containing floats

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/5662aa94c091083f004530d7ed77ec42a93414a4
Fix issue 17874 - Static arrays & memset

Hopefully completes what #3784 started.

https://github.com/dlang/dmd/commit/161e2e038a656f8d849967821cb0c35a77386d32
Merge pull request #8092 from LemonBoy/b17874

Fix issue 17874 - Static arrays & memset
merged-on-behalf-of: Walter Bright 

--

Re: rvalues -> ref (yup... again!)

[kinke via Digitalmars-d]

On Tuesday, 27 March 2018 at 21:52:25 UTC, Rubn wrote:
It happens with LDC too, not sure how it would be able to know 
to do any kind of optimization like that unless it was able to 
inline every single function called into one function and be 
able to do optimize it from there. I don't imagine that'll be 
likely though.


It does it in your code sample with `-O`, there's no call to bar 
and the foo() by-value arg is memcpy'd to the global.


If you compile everything with LTO, your code and all 3rd-party 
libs as well as druntime/Phobos, LLVM is able to optimize the 
whole program as if it were inside a single gigantic 'object' 
file in LLVM bitcode IR, and is thus indeed theoretically able to 
inline *all* functions.

Re: Recursive attribute for virtual functions?

[arturg via Digitalmars-d]

On Tuesday, 27 March 2018 at 23:23:38 UTC, ag0aep6g wrote:


DMD might accept that, but I don't think it works in a 
meaningful way. How do you call the @system one?


Looks like the @safe one will always be called, even from 
@system code:



import std.stdio;

void talk() @system { writeln("@system"); }
void talk() @safe { writeln("@safe"); }

void main() @system
{
talk(); /* Prints "@safe". */
}



you can call them with __traits(getOverloads, T, "name")[index];

you can overload on types attributes and linkage, but seems like 
you can only merge overloads based on types.

[Issue 18433] rdmd doesn't respect DFLAGS for its cache hash

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Seb  ---
https://github.com/dlang/tools/pull/343

--

utf.d codeLength asserts false on certain input

[Anonymouse via Digitalmars-d-learn]

My IRC bot is suddenly seeing crashes. It reads characters from a 
Socket into an ubyte[] array, then idups parts of that (full 
lines) into strings for parsing. Parsing involves slicing such 
strings into meaningful segments; sender, event type, target 
channel/user, message content, etc. I can assume all of them to 
be char[]-compliant except for the content field.


Running it in a debugger I see I'm tripping an assert in utf.d[1] 
when calling stripRight on a content slice[2].



/++
Returns the number of code units that are required to 
encode the code point

$(D c) when $(D C) is the character type used to encode it.
  +/
ubyte codeLength(C)(dchar c) @safe pure nothrow @nogc
if (isSomeChar!C)
{
static if (C.sizeof == 1)
{
if (c <= 0x7F) return 1;
if (c <= 0x7FF) return 2;
if (c <= 0x) return 3;
if (c <= 0x10) return 4;
assert(false);  // <--
}
// ...


This trips it:


import std.string;

void main()
{
string s = "\355\342\256 \342\245\341⮢\256\245 
ᮮ\241饭\250\245".stripRight;  // <-- asserts false

}


The real backtrace:
#0  _D3std3utf__T10codeLengthTaZQpFNaNbNiNfwZh (c=26663461) at 
/usr/include/dlang/dmd/std/utf.d:2530
#1  0x5578d7aa in 
_D3std6string__T10stripRightTAyaZQrFQhZ14__foreachbody2MFNaNbNiNfKmKwZi (this=0x7fff99c0, __applyArg1=@0x7fff9978: 26663461, __applyArg0=@0x7fff9970: 17) at /usr/include/dlang/dmd/std/string.d:2918
#2  0x77a47014 in _aApplyRcd2 () from 
/usr/lib/libphobos2.so.0.78
#3  0x5578d731 in 
_D3std6string__T10stripRightTAyaZQrFNaNiNfQnZQq (str=...) at 
/usr/include/dlang/dmd/std/string.d:2915
#4  0x558e0cc7 in 
_D8kameloso3irc17parseSpecialcasesFNaNfKSQBnQBh9IRCParserKSQCf7ircdefs8IRCEventKAyaZv (slice=..., event=...,parser=...) at source/kameloso/irc.d:1184



Should that not be an Exception, as it's based on input? I'm not 
sure where the character 26663461 came from. Even so, should it 
assert?


I don't know what to do right now. I'd like to avoid sanitizing 
all lines. I could catch an Exception but not so much an 
AssertError.



[1]: https://github.com/dlang/phobos/blob/master/std/utf.d#L2522
[2]: 
https://github.com/zorael/kameloso/blob/master/source/kameloso/irc.d#L1184

[Issue 14855] -cov should ignore assert(0)

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from hst...@quickfur.ath.cx ---
To me it doesn't make sense that `assert(0);` should be counted towards
coverage.  I mean, `assert(0);` is basically the programmer telling the
compiler "this is not supposed to happen" and "this is unreachable code",
meaning that if execution ever gets to this point, the code is wrong and the
program is in an invalid state.  On the flip side, if everything else except
assert(0) were reached during execution, then surely that means the code is
100% covered, since the assert(0)'s are not supposed to ever happen, from the
language's POV.

--

Re: Recursive attribute for virtual functions?

[ag0aep6g via Digitalmars-d]

On 03/28/2018 12:19 AM, arturg wrote:

shouldn't it create a overload?


I don't think so. As far as I know, you can't overload on attributes.

[...]

but this works:

class A
{
     void talk() {}
}

class B : A
{
     alias talk = A.talk;
     void talk(int) {}
}


Because different parameters make overloads.


this works also:

class C
{
     void talk()@system {}
     void talk()@safe {}
}


DMD might accept that, but I don't think it works in a meaningful way. 
How do you call the @system one?


Looks like the @safe one will always be called, even from @system code:


import std.stdio;

void talk() @system { writeln("@system"); }
void talk() @safe { writeln("@safe"); }

void main() @system
{
talk(); /* Prints "@safe". */
}

[Issue 14855] -cov should ignore assert(0)

[d-bugmail--- via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

Re: D vs nim

[Timothee Cour via Digitalmars-d]

that comment was regarding -betterC
RAII (with structs) has been available in D for a while, eg:

```d
struct A{
  ~this(){...}
}

void fun(){
  A a; // when a goes out of scope, will call dtor deterministically
}
```


On Tue, Mar 27, 2018 at 4:15 PM, Ali via Digitalmars-d
 wrote:
> On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:
>>
>> On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote:
>>>
>>> On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour
>>>  wrote:
>>>
>>>
>>> I would like to refocus this thread on feature set and how it compares to
>>> D, not on flame wars about brackets or language marketing issues.
>>
>>
>>
>> I've created a git repo https://github.com/timotheecour/D_vs_nim/ with the
>> goal: up to date and objective comparison of features between D and nim, and
>> 1:1 map of features, tools, idioms and libraries to help D users learn nim
>> and vice versa.
>
>
> How is RAII available in D? I did a quick search on this forum but didnt
> exactly find what I want
>
> I found a comment for Walter (saying it was recently added
> https://forum.dlang.org/post/p1pa01$kc8$1...@digitalmars.com)
>
> What was the added feature that now enables RAII in D

Re: D vs nim

[Ali via Digitalmars-d]

On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:
On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour 
wrote:
On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour 
 wrote:



I would like to refocus this thread on feature set and how it 
compares to D, not on flame wars about brackets or language 
marketing issues.



I've created a git repo 
https://github.com/timotheecour/D_vs_nim/ with the goal: up to 
date and objective comparison of features between D and nim, 
and 1:1 map of features, tools, idioms and libraries to help D 
users learn nim and vice versa.


How is RAII available in D? I did a quick search on this forum 
but didnt exactly find what I want


I found a comment for Walter (saying it was recently added 
https://forum.dlang.org/post/p1pa01$kc8$1...@digitalmars.com)


What was the added feature that now enables RAII in D

[Issue 18433] rdmd doesn't respect DFLAGS for its cache hash

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Seb  ---
Argh, apparently this hasn't been fixed in master and DFLAGS is only looked at
when -conf= is set:

```
> DFLAGS="-version=Foo" ../dmd/generated/linux/release/64/dmd -v foo.d && ./foo
predefs   DigitalMars Posix linux ELFv1 LittleEndian D_Version2 all D_SIMD
D_InlineAsm_X86_64 X86_64 CRuntime_Glibc D_LP64 D_PIC assert D_HardFloat
binary../dmd/generated/linux/release/64/dmd
version   v2.079.0-284-g23b2e2e0d
config../dmd/generated/linux/release/64/dmd.conf
DFLAGS-I../dmd/generated/linux/release/64/../../../../../druntime/import
-I../dmd/generated/linux/release/64/../../../../../phobos
-L-L../dmd/generated/linux/release/64/../../../../../phobos/generated/linux/release/64
-L--export-dynamic -fPIC
```


```
> DFLAGS="-version=Foo" dmd -conf= -I~/dlang/phobos -I~/dlang/druntime/import 
> -c -v foo.d
predefs   Foo DigitalMars Posix linux ELFv1 LittleEndian D_Version2 all D_SIMD
D_InlineAsm_X86_64 X86_64 CRuntime_Glibc D_LP64 D_PIC assert D_HardFloat
binary/home/seb/dlang/dmd/generated/linux/release/64/dmd
version   v2.079.0-284-g23b2e2e0d
config
DFLAGS-version=Foo
```

--

[Issue 17874] Segmentation fault when constructing a struct with a static array of structs containing floats

[d-bugmail--- via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8092

--

[Issue 18433] rdmd doesn't respect DFLAGS for its cache hash

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|rdmd ignores DFLAGS |rdmd doesn't respect DFLAGS
   ||for its cache hash

--- Comment #1 from Seb  ---
Hmm I think the problem is more in DMD not respecting everything from DFLAGS:
However, this has been in master:

cat > foo.d << EOF
void main(){
import std.stdio;
version(Foo)
{
"foo".writeln;
}
else
{
"bar".writeln;
}
}
EOF


```
> dmd -version=Foo foo.d && ./foo
foo
> DFLAGS="-version=Foo" dmd foo.d && ./foo
bar
> DFLAGS="-version=Foo" rdmd --force foo.d
bar
```

(with ~master this correctly yields foo for all commands)

But it looks like rdmd's caching doesn't include a hash of DFLAGS.

```
DFLAGS="-version=Foo" rdmddev foo.d
foo
DFLAGS="-version=Bar" rdmddev foo.d
foo
```

(so I'm renaming this)

--

[Issue 10550] Xorshift32 and Xorshift160 do not generate uniformly-distributed random numbers

[d-bugmail--- via Digitalmars-d-bugs]

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

Zach Bjornson  changed:

   What|Removed |Added

 CC||zbbjorn...@gmail.com

--- Comment #17 from Zach Bjornson  ---
I know this is an old bug, but for the sake of tying up loose ends:

The 13,17,5 triple is valid: On the bottom of page 2 [1], Marsaglia says "Of
those 81 triples with a < c, the triple (c, b, a) also provides a full period
T...". The triple 5,17,13 appears in the 32-bit table, so 13,17,5 is valid.

The triple used in the commit in this issue (13,17,15) is also valid, but was
an unnecessary change. The fix to add the xor was necessary.

[1] http://www.jstatsoft.org/v08/i14/paper

--

Re: Recursive attribute for virtual functions?

[arturg via Digitalmars-d]

On Tuesday, 27 March 2018 at 21:25:33 UTC, ag0aep6g wrote:

On 03/27/2018 11:10 PM, 12345swordy wrote:

Shouldn't it give a warning then?


I wouldn't mind a warning, or even an error. Putting both @safe 
and @system directly on a function is an error, too.


shouldn't it create a overload?
for example this fails:

class A
{
void talk()@safe {}
}

class B : A
{
alias talk = A.talk;
void talk()@system {}
}

but this works:

class A
{
void talk() {}
}

class B : A
{
alias talk = A.talk;
void talk(int) {}
}

this works also:

class C
{
void talk()@system {}
void talk()@safe {}
}

[Issue 17493] nothrow constructor may throw

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Seb  ---
(accidentally reopened - sorry)

--

Re: Building application with LDC and -flto=thin fails in link stage

[Per Nordlöw via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 22:00:42 UTC, Johan Engelen wrote:

Indeed.
Please try to manually link first (without dub) by modifying 
the command on which dub errors:


```
ldmd2 -flto=thin 
-of.dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o ../../.dub/packages/gmp-d-master/gmp-d/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-B287F67CE5FF6145BC229790CFB09607/libgmp-d.a phobos-next/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F0F2FDB01B8401C04D657BCC145D46A5/libknet_phobos-next.a -L--no-as-needed -L-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2

```

-Johan


Yes, that works!

Re: rvalues -> ref (yup... again!)

[H. S. Teoh via Digitalmars-d]

On Tue, Mar 27, 2018 at 09:52:25PM +, Rubn via Digitalmars-d wrote:
> On Tuesday, 27 March 2018 at 20:38:35 UTC, H. S. Teoh wrote:
> > On Tue, Mar 27, 2018 at 08:25:36PM +, Rubn via Digitalmars-d wrote:
> > [...]
> > > _D7example__T3fooTSQr3FooZQnFNbNiNfQrZv:
> > >   push rbp
> > >   mov rbp, rsp
> > >   sub rsp, 3104
> > >   lea rax, [rbp + 16]
> > >   lea rdi, [rbp - 2048]
> > >   lea rcx, [rbp - 1024]
> > >   mov edx, 1024
> > >   mov rsi, rcx
> > >   mov qword ptr [rbp - 2056], rdi
> > >   mov rdi, rsi
> > >   mov rsi, rax
> > >   mov qword ptr [rbp - 2064], rcx
> > >   call memcpy@PLT<- hidden copy
> > [...]
> > 
> > Is this generated by dmd, or gdc/ldc?
> > 
> > Generally, when it comes to performance issues, I don't even bother
> > looking at dmd-generated code anymore.  If the extra copying is
> > still happening with gdc -O2 / ldc -O, then you have a point.
> > Otherwise, it doesn't really say very much.
> > 
> > 
> > T
> 
> It happens with LDC too, not sure how it would be able to know to do
> any kind of optimization like that unless it was able to inline every
> single function called into one function and be able to do optimize it
> from there.  I don't imagine that'll be likely though.

You'll be surprised.  Don't underestimate the power of modern
optimizers.  I've seen LDC do inlining that's so aggressive, that it
essentially evaluated an entire series of function calls at compile-time
(likely on the IR) and generated a single instruction to load the answer
into the return register at runtime. :-D  Of course, it still generated
the individual functions, but those are never actually called at
runtime.

(On one occasion, this produced odd-looking "benchmark" results where the
ldc executable computed the answer in exactly 0ms, whereas everyone else
took a lot longer than that. :-D  (Well, it was probably a few nanosecs
while the CPU decoded and ran the instruction, but I don't think any
benchmark could measure that!))

For your code example, you might want to look at the code generated for
callers of the function, since when compiling individual functions in
isolation, LDC is obligated to follow the ABI, which could include
redundant copying. But if inlining was possible, it could generate very
different code.


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada

[Issue 17493] nothrow constructor may throw

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Walter Bright  ---
Why was this reopened?

--

Re: Building application with LDC and -flto=thin fails in link stage

[Johan Engelen via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 13:28:08 UTC, kinke wrote:

On Monday, 26 March 2018 at 23:32:59 UTC, Nordlöw wrote:

forwarded as `-L-flto=thin` but still errors as


Which is wrong, it's not a ld command-line option (i.e., the 
`-L` prefix is wrong).


Indeed.
Please try to manually link first (without dub) by modifying the 
command on which dub errors:


```
ldmd2 -flto=thin 
-of.dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o ../../.dub/packages/gmp-d-master/gmp-d/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-B287F67CE5FF6145BC229790CFB09607/libgmp-d.a phobos-next/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F0F2FDB01B8401C04D657BCC145D46A5/libknet_phobos-next.a -L--no-as-needed -L-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2

```

-Johan

Re: rvalues -> ref (yup... again!)

[Rubn via Digitalmars-d]

On Tuesday, 27 March 2018 at 20:38:35 UTC, H. S. Teoh wrote:
On Tue, Mar 27, 2018 at 08:25:36PM +, Rubn via 
Digitalmars-d wrote: [...]

_D7example__T3fooTSQr3FooZQnFNbNiNfQrZv:
  push rbp
  mov rbp, rsp
  sub rsp, 3104
  lea rax, [rbp + 16]
  lea rdi, [rbp - 2048]
  lea rcx, [rbp - 1024]
  mov edx, 1024
  mov rsi, rcx
  mov qword ptr [rbp - 2056], rdi
  mov rdi, rsi
  mov rsi, rax
  mov qword ptr [rbp - 2064], rcx
  call memcpy@PLT<- hidden copy

[...]

Is this generated by dmd, or gdc/ldc?

Generally, when it comes to performance issues, I don't even 
bother looking at dmd-generated code anymore.  If the extra 
copying is still happening with gdc -O2 / ldc -O, then you have 
a point. Otherwise, it doesn't really say very much.



T


It happens with LDC too, not sure how it would be able to know to 
do any kind of optimization like that unless it was able to 
inline every single function called into one function and be able 
to do optimize it from there. I don't imagine that'll be likely 
though.

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Walter Bright via Digitalmars-d-announce]

On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily positive. THough I can't 
tell why from the top of my mind.


The act of compiling a buggy program not influence the global state of the 
computer. It should not be necessary to vet code downloaded from the internet 
before even compiling it to ensure it doesn't mess up the system.


CTFE should run in a sandbox. It must be safe to compile code.

Re: Recursive attribute for virtual functions?

[ag0aep6g via Digitalmars-d]

On 03/27/2018 11:10 PM, 12345swordy wrote:

Shouldn't it give a warning then?


I wouldn't mind a warning, or even an error. Putting both @safe and 
@system directly on a function is an error, too.

[Issue 18672] Error in @safe transitive propagation with associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #2 from ag0aep6g  ---
(In reply to Seb from comment #1)
> So DMD already does transitively apply @safe, but apparently if it generated
> for associative arrays this generation doesn't work in all cases.

It's not the associative array. It's just that the generated opAssign isn't
@safe (for no reason):


void main() @safe
{
struct ThrowingElement
{
~this() {}
}

ThrowingElement aa;
/* Accepted. The destructor is apparently inferred as @safe. */
aa = aa;
/* Error: @safe function D main cannot call @system generated
function onlineapp.main.ThrowingElement.opAssign */
}


--

Re: Recursive attribute for virtual functions?

[12345swordy via Digitalmars-d]

On Tuesday, 27 March 2018 at 21:05:32 UTC, ag0aep6g wrote:

On 03/27/2018 11:02 PM, 12345swordy wrote:

Then explain this then.
https://run.dlang.io/is/S2KLs5


B.talk is @safe. The compiler ignores the @system attribute on 
B.talk, because A.talk's @safe attribute takes precedence.


Shouldn't it give a warning then?

[Issue 18670] compiler segfault if `new` on a union type with dip1000

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from hst...@quickfur.ath.cx ---
P.S. Tested on git commit 2e21d0713babf760e4428d6404d733282ef85e8a, just to be
clear.

--

[Issue 18670] compiler segfault if `new` on a union type with dip1000

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from hst...@quickfur.ath.cx ---
Unable to reproduce problem on git master.  Perhaps it has since been fixed?

--

Re: Recursive attribute for virtual functions?

[ag0aep6g via Digitalmars-d]

On 03/27/2018 11:02 PM, 12345swordy wrote:

Then explain this then.
https://run.dlang.io/is/S2KLs5


B.talk is @safe. The compiler ignores the @system attribute on B.talk, 
because A.talk's @safe attribute takes precedence.

Re: DLS : an attempt at a language server

[WebFreak001 via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 18:08:14 UTC, Laurent Tréguier wrote:

Hello, D community!

I've been looking at D for a while now, but never got to really 
use it. And now that Microsoft initiated the Language Server 
Protocol, I thought about trying to make a language server 
using DCD, DFMT and D-Scanner.
It only supports formatting with DFMT and basic autocompletion 
with DCD (for now). I've successfully got it working with both 
VSCode [1] and Atom [2], maybe I'll try to make extensions for 
some other editors as well.


Also now that I've actually tried the language, I have to say I 
really like it :)


[1]: 
https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls

[2]: https://atom.io/packages/ide-dlang


neat, I am also planning on including dcd inside my language 
server, did everything just work or did you have issues with 
threading and messaging etc and what were your experiences on it?


I see that you have an auto updater, I might as well steal that 
functionality for me :p


Can you list what else makes your language server special? Have 
you maybe also considered contributing on workspace-d/serve-d? ;)

[Issue 18670] compiler segfault if `new` on a union type with dip1000

[d-bugmail--- via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||ice
 CC||hst...@quickfur.ath.cx
   Severity|major   |critical

--- Comment #1 from hst...@quickfur.ath.cx ---
This is an ICE; upping priority.

--

[Issue 18672] Error in @safe transitive propagation with associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 18603] Illegal instruction: 4 on Mac OS 10.7.5 Leopard

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/427674142aecdd820a017c73b75508d4cddb1dfe
Fix Issue 18603 - Illegal instruction: 4 on Mac OS 10.7.5 Leopard

https://github.com/dlang/installer/commit/47830a15d1a576b683c92b4bb4adc4a1d83a2b5d
Merge pull request #308 from wilzbach/fix-18603

Fix Issue 18603 - Illegal instruction: 4 on Mac OS 10.7.5 Leopard

--

Re: Recursive attribute for virtual functions?

[12345swordy via Digitalmars-d]

On Tuesday, 27 March 2018 at 20:49:25 UTC, ag0aep6g wrote:

On 03/27/2018 10:39 PM, 12345swordy wrote:

class A
{
     @recursive @safe void talk()

[...]

}
class B : A
{
     override void talk() // @safe attribute added by 
recursive attribute and can not be removed

[...]

}


It already works like that. B.talk is @safe, and you can't make 
it @system. You can mark it as @system, that gets overridden by 
A.talk's @safe.


https://run.dlang.io/is/BlH8bp

Then explain this then.
https://run.dlang.io/is/S2KLs5

[Issue 18672] Error in @safe transitive propagation with associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

Summary|@safe should be |Error in @safe transitive
   |transitively propagated |propagation with
   ||associative arrays
   Severity|enhancement |normal

--- Comment #1 from Seb  ---
Argh I accidentally hit submit.

The reason for the resubmission is that the following code compiles fine
already:

cat > main.d << EOF
void main() @safe
{
struct Foo
{
int i;
~this() // <- no need to annotate with @safe explicitly here
{
assert(1);
}
void m(){}  // <- no need to annotate with @safe explicitly here
}

Foo foo;
foo.m();
}
EOF

So DMD already does transitively apply @safe, but apparently if it generated
for associative arrays this generation doesn't work in all cases.

--

[Issue 18672] New: @safe should be transitively propagated

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18672
   Summary: @safe should be transitively propagated
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

cat > main.d << EOF
void main() @safe
{
struct ThrowingElement
{
int i;
~this()
{
assert(1);
}
}

ThrowingElement[int] aa;
aa[0] = ThrowingElement(0);
}
EOF


(resubmission of the example of #18592 as I do believe that the compiler should

--

[Issue 18663] std.random.isSeedable has false positives

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18663] std.random.isSeedable has false positives

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e9f56ba3b293670b7b7173ae75bf465448fff7ac
Fix Issue 18663 - std.random.isSeedable has false positives

https://github.com/dlang/phobos/commit/6400ada30fc296daef439535aea5b5b0ede6a3a0
Merge pull request #6348 from n8sh/isSeedable-fix

Fix Issue 18663 - std.random.isSeedable has false positives
merged-on-behalf-of: Jack Stouffer 

--

Re: Recursive attribute for virtual functions?

[ag0aep6g via Digitalmars-d]

On 03/27/2018 10:39 PM, 12345swordy wrote:

class A
{
     @recursive @safe void talk()

[...]

}
class B : A
{
     override void talk() // @safe attribute added by recursive 
attribute and can not be removed

[...]

}


It already works like that. B.talk is @safe, and you can't make it 
@system. You can mark it as @system, that gets overridden by A.talk's @safe.


https://run.dlang.io/is/BlH8bp

Re: rvalues -> ref (yup... again!)

[H. S. Teoh via Digitalmars-d]

On Tue, Mar 27, 2018 at 08:25:36PM +, Rubn via Digitalmars-d wrote:
[...]
> _D7example__T3fooTSQr3FooZQnFNbNiNfQrZv:
>   push rbp
>   mov rbp, rsp
>   sub rsp, 3104
>   lea rax, [rbp + 16]
>   lea rdi, [rbp - 2048]
>   lea rcx, [rbp - 1024]
>   mov edx, 1024
>   mov rsi, rcx
>   mov qword ptr [rbp - 2056], rdi
>   mov rdi, rsi
>   mov rsi, rax
>   mov qword ptr [rbp - 2064], rcx
>   call memcpy@PLT<- hidden copy
[...]

Is this generated by dmd, or gdc/ldc?

Generally, when it comes to performance issues, I don't even bother
looking at dmd-generated code anymore.  If the extra copying is still
happening with gdc -O2 / ldc -O, then you have a point. Otherwise, it
doesn't really say very much.


T

-- 
People tell me that I'm skeptical, but I don't believe them.

Recursive attribute for virtual functions?

[12345swordy via Digitalmars-d]

For example

class A
{
@recursive @safe void talk()
{
writeln("Hi");
}

}
class B : A
{
override void talk() // @safe attribute added by recursive 
attribute and can not be removed

{
writeln("Bye");
}
}

I have notice that potential bugs can slip by the compiler during 
compile time, and I purpose this as way to counter them.


Alex

Re: rvalues -> ref (yup... again!)

[Rubn via Digitalmars-d]

On Tuesday, 27 March 2018 at 15:50:37 UTC, Atila Neves wrote:

It's fine for references to
just be references in D. We're not struggling to make 
references
move-able in D, that's not a thing, we already have move 
semantics.

Any extension of this conversation about references into C++
rvalue-references (T&&) and or move-semantics are red-herrings.
There's no such problem in D that needs to be resolved, and the
existing solution is excellent.


If I'm reading you correctly (which I might not), you seem to 
be saying that there's a way forward in which:


1) D's move semantics aren't affected
2) No rvalue references are introduced
3) Temporaries can bind to ref const(T)

I'd love to know what that would look like.

Atila



Well currently if you only have this implemented:

void foo(const ref Type);

Type temp = Type(10);
foo(temp);

Where the hell are you going to do your move semantics? You can't 
do it anyways currently, it's completely meaningless cause you 
can't.


void foo(Type);
void foo(const ref Type);

foo(Type(10));

Now we have move semantics with an additional definition.


With the proposed change, nothing about that would change. A 
temporary is only passed to a const ref as a "last resort". If it 
can do a move instead, it will do the move. The only change that 
is desired is to make the first sample code above have nicer 
syntax. That's it, like in the first example you don't care about 
it being a temporary or not.

Re: rvalues -> ref (yup... again!)

[Peter Campbell via Digitalmars-d]

On Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote:

That's exactly what I've been saying. For like, 9 years..
It looks like this:
https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md
 (contribution appreciated)


I've followed this thread since it was made as this has been one 
of the very few disappointments of the language for me. I only 
tend to write game code and use D for hobbyist projects whilst 
using C++ full-time as a junior at a small games company. Even if 
I take the attitude that I should use D as it is intended, 
instead of trying to write C++ by using D, it always felt 
unnecessarily obstructive to require me to make a temporary 
variable to avoid copying something simple like a vector or a 
matrix. It feels very restrictive when trying to express 
mathematical calculations in a concise manner.


Thanks for writing that DIP, you have covered everything I would 
love to see in great detail with good examples! I honestly 
couldn't think of anything more that could be added.

[Issue 18671] New: Implement loop unrolling in dmd's optimizer

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18671
   Summary: Implement loop unrolling in dmd's optimizer
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

It has been known for a while that dmd's optimizer tends to lag behind
gdc/ldc's when it comes to the performance of the generated code.  While this
may give the appearance of general poor quality of the optimizer, closer
inspection reveals that actually dmd's optimizer does perform many standard
optimization operations, and arguably pretty well at it (it even performs code
hoisting from loops, for example). One big reason it fails to generate code
with performance competitive with ldc/gdc is because, as Walter himself said,
it doesn't unroll loops.

When it comes to optimization, there is often a domino effect where one
optimization leads to opportunities for further optimizations, whereas if that
first optimization wasn't performed, it also closes the door to subsequent
optimizations.  Loops being generally the locus of most performance-sensitive
code means that loop optimizations are especially sensitive to this effect, and
loop unrolling is an important step that could often lead to further
optimization opportunities.  Missing this step is a big reason why dmd's
optimizer often doesn't produce competitive code over ldc/gdc.

This has been talked about often, but it's about time it's logged as a real
request so that it won't be forgotten (and, one hopes, the chances of it
actually being implemented might increase just a tad further away from zero).

tl;dr: please implement loop unrolling in dmd. ;-)

--

Re: rvalues -> ref (yup... again!)

[Rubn via Digitalmars-d]

On Tuesday, 27 March 2018 at 07:33:12 UTC, Atila Neves wrote:

On Tuesday, 27 March 2018 at 00:30:24 UTC, Rubn wrote:

On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote:

C++ T&& (Rvalue reference) -> D T


Not really, in C++ it is an actual reference and you get to 
choose which function actually does the move. In D it just 
does the copy when passed to the function.


It doesn't copy.


It copies the memory, so it does 2 memcpy's in the sense where as 
C++ only calls its move constructor once.



So you can't do this in D.

void bar(T&& t)
{
// actually move contents of T
}

void foo(T&& t)
{
bar(std::forward(t)); // Can't do this in D without 
making another actual copy cause it isn't a reference

}



You can most definitely do this in D:

void bar(T)(auto ref T t) {
// T is a ref for lvalues, by value for rvalues
}

void foo(T)(auto ref T t) {
import std.functional: forward;
bar(forward!t);
}


More to the point:

import std.stdio;

struct Foo {
ubyte[] data;

this(int n) {
writeln("ctor n = ", n);
data.length = n;
}

this(this) {
writeln("postBlit n = ", data.length);
data = data.dup;
}
}

void foo(T)(auto ref T t) {
import std.functional: forward;
bar(forward!t);
}

void bar(T)(auto ref T t) {
writeln("bar: ", t.data[0]);
}

void main() {
bar(Foo(10));
auto f = Foo(5);
f.data[0] = 42;
bar(f);
}


The output is:

ctor n = 10
bar: 0
ctor n = 5
bar: 42

Notice the lack of "postBlit" in the output. No copies were 
made. In D, by value *does not* mean copy. And given that, 
contrary to C++, the compiler doesn't write the postBlit 
constructor for you, you'd only ever get copies if you 
implemented it yourself!


Well for starters your code is wrong. You are calling bar() 
instead of foo().


D has hidden implementation details, from your perspective it 
looks like it isn't doing any copying from the high-level 
viewpoint, but from the low-level viewpoint your object has been 
copied (moved memory) multiple times.


struct Foo {
ubyte[1024] data;
}

void foo(T)(auto ref T t) {
import std.functional: forward;
bar(forward!t);
}

Foo gfoo;

void bar(T)(auto ref T t) {
import std.algorithm.mutation : move;
move(t, gfoo);
}

void main() {
foo(Foo(10));
}

_D7example__T3fooTSQr3FooZQnFNbNiNfQrZv:
  push rbp
  mov rbp, rsp
  sub rsp, 3104
  lea rax, [rbp + 16]
  lea rdi, [rbp - 2048]
  lea rcx, [rbp - 1024]
  mov edx, 1024
  mov rsi, rcx
  mov qword ptr [rbp - 2056], rdi
  mov rdi, rsi
  mov rsi, rax
  mov qword ptr [rbp - 2064], rcx
  call memcpy@PLT<- hidden copy


Then the other copy is in move() to gfoo. That hidden copy will 
happen for every additional function call you try to pass Foo 
through.



What's a concrete example that you would be required to know 
whether a const& is a temporary or not.


To know whether or not you can move instead of copy. If it's a 
temporary, you can move. If it's not, you have to copy. Since 
temporaries bind to const T& in C++, you might have a 
temporary, or you might have an lvalue. Since you don't know, 
you have to copy. To support move semantics, C++ got T&&, which 
lvalues can't bind to. So if you have a T&&, you know it's 
about to go away and a move is possible.


In D, if it's ref then it can't be a temporary. If it's a value 
then it can, and it gets moved.


D already has move semantics, an easy solution to this is to just 
use another keyword. It doesn't have to bind to const ref to get 
what is desired:


// what was suggested in the original DIP, since scope is being 
used for something else now

void foo(@temp ref value)
{
}

Now you don't have this problem. You only get this behavior when 
you basically say you don't care whether it is a temporary or not.


So what's your problem with it now ?

I've come across a few pains of such. It make be easier to use 
but it comes at a performance hit. In part binaries become 
huge because of how "init" is implemented.


struct StaticArray(T, size_t capacity)
{
size_t length;
T[capacity] values;
}

Copying the above structure copies unnecessary data for any 
move/copy operation. Eg when length = 0, it'll still copy 
everything. This includes initialization.


This is that rare type for which moving is the same as copying. 
In that case (assuming it gets copied, see my reply to Manu), 
pass by ref. You won't be able to pass in temporaries, but I 
think that's a small price to pay for not having rvalue 
references.


In this case specifically, I don't know why you wouldn't just 
slice it when passing to functions.


Atila


This wasn't an example for rvalue references. This was an example 
illustrating the negative results of the current "pain-free" 
system. I have a 100 mb binary, 90 mb of that come from a single 
structure. I mean sure you don't really have to worry about 
implementing move constructors and such but it is far from being 
pain free, 

Re: Where is TypeInfo stored?

[Jeremy DeHaan via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 19:06:38 UTC, Adam D. Ruppe wrote:

On Tuesday, 27 March 2018 at 18:56:58 UTC, Jeremy DeHaan wrote:

Are these put into the text or data segments?


Yeah, they are in the data segment as static data (just like if 
you declared your own static array).


Awesome, thanks. That is what I was hoping for.

[Issue 18184] std.zip should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a67d667d8b4234be99dc9ffde901dc88825153fb
Work On Issue 18184 - std.zip should be usable in @safe

https://github.com/dlang/phobos/commit/4ad1477bab05511c79508d49af9e74a6fd3b3147
Merge pull request #6254 from JackStouffer/issue18184

Work On Issue 18184 - std.zip should be usable in @safe
merged-on-behalf-of: Jack Stouffer 

--

Re: Where is TypeInfo stored?

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 18:56:58 UTC, Jeremy DeHaan wrote:

Are these put into the text or data segments?


Yeah, they are in the data segment as static data (just like if 
you declared your own static array).

Re: "in" no longer "scope" since 2.079.0?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, March 27, 2018 16:16:15 Adam D. Ruppe via Digitalmars-d-learn 
wrote:
> On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote:
> > it was deemed too dangerous to have in suddenly really mean
> > both scope and const, because it would potentially break a lot
> > of code.
>
> To be frank, this pisses me off to a ridiculous extent because if
> it "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler
> would now just be actually telling you the truth.
>
> And many of us have spent years describing what it is supposed to
> do (it WAS documented in the spec the whole time!) and how to use
> it properly,

All it ever said about scope was that it prevented references from escaping.
It did not explain what that meant for any particular type. Reasonable
assumptions could be made about what it probably meant, but it was never
actually explained. DIP 1000 explains the semantics, and it clearly goes
beyond whatever might have been originally planned, because it applies scope
to far more than just parameters in order to make it work.

> so much code using it may actually be totally
> correct, and keeping the original behavior would actually help
> adoption of the new rules because more code would be compatible
> with it!
>
> We need to stop being cowards about compile errors. The compiler
> actually correctly flagging an error that it skipped before isn't
> code breakage. That's FIXING broken code by actually drawing
> attention to the ALREADY EXISTING bug.

Well, if you want that, you'll have to talk Walter into it. In this case, I
very much agree with him. Based on discussions on it in the past, and many
of the questions that have popped up over the years, I think that it's quite
clear that a lot of folks have been using in without really understanding
it, meaning that I don't think that it's at all safe to say that the average
programmer used in expecting anything like the semantics of DIP 1000, and
the changes that -dip1000 requires means that scope needs to be used in a
lot more places than just the function parameters, meaning that even if the
programmer had meant in / const scope in the way that DIP 1000 means scope,
their code is going to have quite a few compilation errors with the change.
This wouldn't be a few compilation errors here and there that would catch
bugs. This would be compilation errors all over the place because either in
was misused and/or because scope is required in a bunch of extra places to
make it work.

Now, I there are enough issues with using -dip1000 that I don't know how
Walter is ever going to make it the default behavior anyway. So, maybe
there's room to argue that it causes enough breakage on its own that it
doesn't matter if in breaks everything, but I think that it's very much a
stretch to argue that most of the uses of in in the wild match what -dip1000
means.

Personally, I think that it was mistake in the first place to have a keyword
be an alias for another keyword - let alone two keywords - but the only way
to fix that would be to deprecate in, and given that Walter's reaction was
to make in const rather than deprecate it, I question that he could be
talked into doing so. It _is_ used by a lot of code, whether the programmer
meant anything like DIP 1000 means or not.

- Jonathan M Davis

Where is TypeInfo stored?

[Jeremy DeHaan via Digitalmars-d-learn]

I was doing some experiments with the runtime and I didn't notice 
the TypeInfo instances being allocated by the GC. Are these put 
into the text or data segments? Is there anyway to find out more 
about this process?

Re: DLS : an attempt at a language server

[Laurent Tréguier via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 18:32:40 UTC, Anton Pastukhov wrote:

Ahem... https://github.com/Pure-D/serve-d


I know, but I still wanted to have a bit of fun anyway

[Issue 18550] Offline option for dlang.org makefile

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Argh, is there a way to tell the `phobos-prerelease` target to just use the
local dmd repo instead of yet another remote cloning?

--

[Issue 18550] Offline option for dlang.org makefile

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from hst...@quickfur.ath.cx ---
Thanks for taking the time to clarify.

I simply assumed it was downloading old releases because it needed to generate
tarballs and whatnot.  I've been on git master for too long, I don't even know
which official release we're on anymore. :-D

Is there any way to direct it to use the locally cloned and already-built dmd
instead?  I mean, it seems a little excessive to have to separately clone the
dmd repo when I already have one on hand.

Also, is the DIFFABLE=1 thing documented anywhere?  I admit I didn't look very
hard, I was just using the plain `html` target out of years of habit.

Anyway, the system incompatibility seems to have gone away with the latest git
pull.  I don't know if it was an actual incompatibility, or if it was caused by
dub not liking it when I interrupt it with ctrl-C and then try to rebuild again
afterwards, or something like that.  (I know it shouldn't be a problem, but
sometimes these things do happen.)

Basically, I would like to have the option of being able to build docs without
network access.

--

Re: DLS : an attempt at a language server

[Anton Pastukhov via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 18:08:14 UTC, Laurent Tréguier wrote:

Hello, D community!

I've been looking at D for a while now, but never got to really 
use it. And now that Microsoft initiated the Language Server 
Protocol, I thought about trying to make a language server 
using DCD, DFMT and D-Scanner.
It only supports formatting with DFMT and basic autocompletion 
with DCD (for now). I've successfully got it working with both 
VSCode [1] and Atom [2], maybe I'll try to make extensions for 
some other editors as well.


Also now that I've actually tried the language, I have to say I 
really like it :)


[1]: 
https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls

[2]: https://atom.io/packages/ide-dlang


Ahem... https://github.com/Pure-D/serve-d

Re: "in" no longer "scope" since 2.079.0?

[Schrom, Brian T via Digitalmars-d-learn]

On Tue, Mar 27, 2018 at 03:27:07AM -0600, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> 
> Because scope has mostly done nothing (it only affected delegates), in has
> effectively been const without scope for its entire existence in D2 in spite
> of the fact that it was supposed to be the same as const scope. Now that DIP
> 1000 is being implemented, and scope is actually going to do something for
> more than just delegates, it was deemed too dangerous to have in suddenly
> really mean both scope and const, because it would potentially break a lot
> of code. So, in order to prevent such breakage, in was changed to officially
> only mean const instead of const scope. So, what it's meant in practice
> hasn't really changed, but the spec has.
> 
> https://issues.dlang.org/show_bug.cgi?id=17928
> 
> - Jonathan M Davis
> 

FWIW,  this is  very much  my opinion,  but if  I am  understanding this
correctly, the difference  between the two prototypes below, that I just
happened to  be working on, (assuming they  are equivalent with  the old
'in' behavior)  is the  difference between  D being  really great  and D
being 'meh' and not much better than C++ syntax wise.

void copyFrom( in size_t baseIndex, in WFFRecord from, in size_t[] args )

vs.

void copyFrom( scope const size_t baseIndex, scope const WFFRecord from, scope 
const size_t[] args )*

For me, I think the second is so much worse for two reasons:
1) The prototype is obfuscated in attribute puke and those extra few
   moments to separate the attributes from the parameters bring back
   memories of C++ and needing to put parameters on their own lines.

2) It's  approaching the line  length that  just works all  the time
   with whatever editor I'm in.

I really  hope that  a better  solution to 'in'  is found.   I'd greatly
prefer breaking code (at compile time) and forcing it to be better code,
but my programs are short and easy to update.

Actually,  if  arguments to  functions  were  default "logically  input"
meaning that they couldn't be  changed, returned, and the compiler could
make smart optimizations and pass by  reference or value, etc that would
be way better than needing any annotation at all.  (Also @safe and maybe
pure  by  default too,  :)  I'd  rather  opt-in  to the  'this'  context
pointers)

* I realize  that scope is redundant  but I'm not going  to remember all
  the specific "rules" about it when I  want to say that the argument is
  an INPUT  and don't  mutate or  allow it to  be be  mutated it  in ANY
  surprising way.


Brian

Comparing In-Person Interpretation Vs Video Interpretation

[Globibo via Digitalmars-d-learn]

In recent years, thanks to the rapid and continuous advancements 
in the field of technology, more companies are doing businesses 
across borders. Hence, language interpretation services have 
become extremely crucial in today's world. There are different 
types of interpretation services such as video interpretation, 
face-to-face interpretation, and telephone interpretation. The 
question is which one is the most superior. The answer to this 
question is that each type has its own share of pros and cons. 
The difference between in-person and video interpretation can be 
understood by trying to understand their features.




In-Person Interpretation

In a majority of scenarios, face-to-face interpretation is the 
best choice. Since an interpreter is physically present inside 
the room, he or she can easily read the facial expression and the 
body language of the speaker. Thus an in-person interpreter can 
easily pick up finer nuisances like when a topic requires further 
explanation, has a query or a speaker is confused.


Video Interpretation

Such an interpretation service can save your time or money. When 
you are unable to get a professional interpretation service 
nearby, the best option for you is to go for a video interpreting 
or telephone interpreting service. Video interpreting service is 
a remote one and is an excellent choice in emergency situations 
like at a hospital's Emergency Room. Cost is an important factor 
for choosing it since you need to spend more for ensuring the 
travel of a professional interpreter to your site.


www.language-school.hk

Re: rvalues -> ref (yup... again!)

[Manu via Digitalmars-d]

On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d
 wrote:
> On Monday, 26 March 2018 at 19:24:13 UTC, Manu wrote:
>>
>> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d
>>  wrote:
>>>
>>> On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote:


 Forked from the x^^y thread...
 
>>>
>>>
>>>
>>> C++ T&& (forwarding reference) -> D auto ref T
>>> C++ T&& (Rvalue reference) -> D T
>>> C++ const T& -> D T
>>
>>
>> Yeah, no... T may be big. Copying a large thing sucks. Memory copying
>> is the slowest thing computers can do.
>
>
> That's _if_ T is big and _if_ it even gets copied,

You've just described the exact anatomy of a ref function!
You wouldn't write a function to receive T by ref UNLESS T was both
big, and the function probably won't inline (therefore definitely
copy), and that condition will be triggered by any of the list of
reasons I've said a bunch of times (extern, dll, lib, virtual, etc).
People don't just love writing ref (well, some people might), but they
use it deliberately, typically in user-facing boundary API's for these
exact reasons.


> the combination of which
> I think happens very rarely. When that happens I think that the temporary
> isn't a big deal. This code:
>
> struct Foo { int[1024] data; }
> int byValue(Foo f) { return f.data[42]; }
>
> Generates this assembly (ldc2 -O3, clang does the same for C++):
>
>  <_D3foo7byValueFSQo3FooZi>:
>0:   8b 84 24 b0 00 00 00moveax,DWORD PTR [rsp+0xb0]
>7:   c3  ret
>
> And I wrote a type for which a move and a copy are the same on purpose: in
> "real life" it's more likely that the memory will be dynamically allocated,
> probably held in a slice, and moved instead.
>
> Are there cases in which there will be an expensive copy? Yes, then pass by
> ref/pointer. But measure first, and prefer to pass by value by default.

Right. I'm talking about deliberate use of ref... Or *existing*
(deliberate) use of ref, as is the case in almost all my my cases. The
code already exists.
As you assess, use of ref in D is fairly rare. I've been looking for
cases where other people are inconvenienced by this... hard to find.
I suspect there are reasons for this. One of them is that this
inconvenience suppresses it; ie, you will choose not to use a ref even
when you might prefer to. Others include the fact that extern(C++)
isn't super popular, DLL's aren't popular, closed-source distributed
code is non popular, OOP is not popular, etc.


> It's different in C++ - stick a std::vector or std::string in your struct
> and passing by value (usually) copies the dynamically allocated memory. In D
> it moves.

Only if you ARE moving, and not copying. D must deep copy too if you
actually copy.
Your example assumes C++ doesn't have a move constructor. D has
implicit move semantics, so you can only make an equivalent comparison
where C++ also defines the move constructor so the move case doesn't
pollute the ref comparison.
Also, irrespective of whether move semantics are performed (eliding
potential deep copying, as in your example), the binary memcpy still
has to be performed when handling values by-val, unless RVO (we're not
talking about return values), or inlining is able to eliminate it.
Also, we're not talking about move semantics!


>> As an API author, exactly as in C++, you will make a judgement on a
>> case-by-case basis on this matter. It may be by-value, it may be by
>> const-ref. It depends on a bunch of things, and they are points for
>> consideration by the API author, not the user.
>
>
> You can still do that in D. There well may be a reason to pass by const ref.
> I'm just saying that there aren't that many, and in that in those rare cases
> a temporary is fine. Especially if the alternative are rvalue references.

We're not talking about rvalue references, we're talking about normal
references >_<


>> He's trying to say that C++ introduced rvalue references because normal
>> references weren't able to allow for move semantics to exist. It's a
>> red-herring. D already has move semantics, they work well, and they're not
>> on trial here.
>>
>> In C++'s case, it's not that references were deficient at being
>> references that C++ needed rval-references, it's that references were
>> deficient at being move-able.
>
>
> There were deficient at being moveable because temporaries can bind to const
> T&.

... what? That's just not true at all.
If temporaries couldn't bind to C++ ref, then you *definitely*
wouldn't be able to move it, because you can guarantee that someone
else owns the reference. You can't move references, under any
circumstances, in either language... and that's actually the whole
point of references.

rvalue references were introduced in C++ to capture the calls with
rvalues into a separate function call, exactly the same way as the
by-value overload will catch the rvalues in D (and perform an implicit

DLS : an attempt at a language server

[Laurent Tréguier via Digitalmars-d-announce]

Hello, D community!

I've been looking at D for a while now, but never got to really 
use it. And now that Microsoft initiated the Language Server 
Protocol, I thought about trying to make a language server using 
DCD, DFMT and D-Scanner.
It only supports formatting with DFMT and basic autocompletion 
with DCD (for now). I've successfully got it working with both 
VSCode [1] and Atom [2], maybe I'll try to make extensions for 
some other editors as well.


Also now that I've actually tried the language, I have to say I 
really like it :)


[1]: 
https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls

[2]: https://atom.io/packages/ide-dlang

Re: DConf 2018 Hackathon -- now open to the public free of charge

[Jack Stouffer via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 14:04:29 UTC, Mike Parker wrote:
Yesterday, I made the announcement that the Hackathon would be 
open to anyone willing to pay $100 to get in. That idea has now 
been nixed. Instead, anyone can come in for the full day 
completely free. It's like a big Munich Meetup!


Wow, it's great news that the D Foundation can afford to do that 
;)

Re: "in" no longer "scope" since 2.079.0?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Mar 27, 2018 at 04:16:15PM +, Adam D. Ruppe via Digitalmars-d-learn 
wrote:
> On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote:
> > it was deemed too dangerous to have in suddenly really mean both
> > scope and const, because it would potentially break a lot of code.
> 
> To be frank, this pisses me off to a ridiculous extent because if it
> "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler would
> now just be actually telling you the truth.
> 
> And many of us have spent years describing what it is supposed to do
> (it WAS documented in the spec the whole time!) and how to use it
> properly, so much code using it may actually be totally correct, and
> keeping the original behavior would actually help adoption of the new
> rules because more code would be compatible with it!
> 
> We need to stop being cowards about compile errors. The compiler
> actually correctly flagging an error that it skipped before isn't code
> breakage.  That's FIXING broken code by actually drawing attention to
> the ALREADY EXISTING bug.

+1.  I think our current phobia of breaking existing code is getting a
little too far on the side of paranoia.  "Breaking" existing buggy code
with a compiler error is a good thing.  It's actually helping users find
bugs in the code, and I'm sure any reasonable user would appreciate
that!  Certainly, I did when it happened to me in the past.


T

-- 
People say I'm arrogant, and I'm proud of it.

Re: How to use annotation get key name?

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 15:38:48 UTC, Brian wrote:
but you don't understand my means, I want have keys with 
multiple indeterminate names.


You can pass an associative array (or better yet, a struct 
containing one) as a UDA and then use the regular loop over its 
keys and values.


struct Table { string[string] keys_and_values; }

@Table(["name1": "users", "name2" : "users111"])
void foo() {}


D's UDAs are just a value attached to the name, so all normal 
rules of types apply.

Re: "in" no longer "scope" since 2.079.0?

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 09:27:07 UTC, Jonathan M Davis wrote:
it was deemed too dangerous to have in suddenly really mean 
both scope and const, because it would potentially break a lot 
of code.


To be frank, this pisses me off to a ridiculous extent because if 
it "breaks" at all... THAT CODE WAS ALREADY BROKEN. The compiler 
would now just be actually telling you the truth.


And many of us have spent years describing what it is supposed to 
do (it WAS documented in the spec the whole time!) and how to use 
it properly, so much code using it may actually be totally 
correct, and keeping the original behavior would actually help 
adoption of the new rules because more code would be compatible 
with it!


We need to stop being cowards about compile errors. The compiler 
actually correctly flagging an error that it skipped before isn't 
code breakage. That's FIXING broken code by actually drawing 
attention to the ALREADY EXISTING bug.

Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side

[H. S. Teoh via Digitalmars-d-announce]

On Tue, Mar 27, 2018 at 09:27:16AM -0400, Steven Schveighoffer via 
Digitalmars-d-announce wrote:
> On 3/26/18 9:26 AM, Atila Neves wrote:
> > On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote:
[...]
> > > It's simple. Unittests in imported modules should not be visible.
> > > They should be compiled as if -unittest was not passed.
> > > 
> > > Even Walter and Andrei are supportive:
> > > https://github.com/dlang/dmd/pull/6375#issuecomment-373487247
> > > 
> > 
> > That would completely break __traits(getUnitTests).
> 
> I'm sure we could find a way to keep the features here, 99.99% of the
> time, you don't care about, nor want to parse or semantic, an imported
> module's unit tests. Only specialized unit test frameworks care about
> this feature.
> 
> It could be as simple as, if you use __traits(getUnitTests,
> modulename) anywhere in a module, then that module is imported the
> traditional way. Or we could create a specialized "import unittest"
> syntax for this purpose.
[...]

Yeah, since __traits(getUnitTests) is inside the compiler, it could in
theory be as simple as:

- `import abc;` - compiler lexes and parses abc, but leaves
  unittests alone (but still present as AST nodes with no
  semantic run). Basically, module abc is parsed as if
  `-unittest` is not present.

- `__traits(getUnitTests)` triggers semantic on unittest AST
  nodes of the target module.

Does __traits(getUnitTests) work if you don't specify `-unittest`? If
so, then the solution is probably already there.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

Re: rvalues -> ref (yup... again!)

[Atila Neves via Digitalmars-d]

On Tuesday, 27 March 2018 at 02:41:12 UTC, Manu wrote:

He's trying to say that C++ introduced rvalue references 
because normal references weren't able to allow for move 
semantics to exist. It's a red-herring. D already has move 
semantics, they work well, and they're not on trial here.


In C++'s case, it's not that references were deficient at being
references that C++ needed rval-references, it's that 
references were

deficient at being move-able.


There were deficient at being moveable because temporaries can 
bind to const T&.



That is not a problem that exists in D.


Because temporaries can't bind to ref const(T).


It's fine for references to
just be references in D. We're not struggling to make references
move-able in D, that's not a thing, we already have move 
semantics.

Any extension of this conversation about references into C++
rvalue-references (T&&) and or move-semantics are red-herrings.
There's no such problem in D that needs to be resolved, and the
existing solution is excellent.


If I'm reading you correctly (which I might not), you seem to be 
saying that there's a way forward in which:


1) D's move semantics aren't affected
2) No rvalue references are introduced
3) Temporaries can bind to ref const(T)

I'd love to know what that would look like.

Atila

Re: Optional type - how to correctly reset a wrapped immutable T

[SimonN via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 15:28:40 UTC, jmh530 wrote:

static if (isMutable!T)
bag[0] = rhs;
else
bag = [rhs];


I like this idea. I'd even take it a step futher:

When T is a pointer or class reference, then we can put the 
reference on the stack (instead of into the array) and handle 
assignments like Rebindable handles assignments -- provided that 
Rebindable really is 100 % safe to the outside, see my concerns 
from 2 posts above. In this case (static if), we won't even 
declare the array T[] bag, and instead implement as T value, bool 
isPresent.


When T is a mutable value type, it goes on the stack, too. Again 
no array.


When T is a const/immutable/inout value type, we declare the 
array as before and rebind on assignment with bag = [rhs], as you 
proposed here.


-- Simon

Re: How to use annotation get key name?

[Brian via Digitalmars-d-learn]

On Monday, 26 March 2018 at 08:50:31 UTC, Simen Kjærås wrote:

On Monday, 26 March 2018 at 08:29:31 UTC, Brian wrote:

Rust sample code:

#[cfg(name = "users")]

PHP sample code:

/*
@Table(name = "users")
*/

Java sample code:

@Table(name = "users")

How to use dlang get key name?


If I understand your question correctly:

struct Table {
string name;
}

struct Foo {
@Table("foo")
int n;
}

unittest {
import std.traits;

string name = getUDAs!(Foo.n, Table)[0].name;
}

--
  Simen


Thanks.
but you don't understand my means, I want have keys with multiple 
indeterminate names.


Rust sample code:

#[cfg(name1 = "users", name2 = "users111")]

PHP sample code:

/*
@Table(name2 = "users", name2 = "users111")
*/

Java sample code:

@Table(name2 = "users111", name1 = "users")

How to use dlang get key name?

Don't have support get key function?

How to do?

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Uknown via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 14:51:30 UTC, bachmeier wrote:

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between 
D and nim (to help deciding what language to use), and 1:1 map 
of features and libraries to help D users learn nim and vice 
versa.


PRs are welcome and merged fast


Named parameter arguments is an advantage? I would not consider 
using a language with named parameter arguments. At best, 
claiming it's an advantage is arbitrary.


You might have better luck comparing the languages if you got 
rid of the +1/-1 thing.


I agree with you. A lot of the parameters selected seem 
arbitrary. A lot of the advantages and disadvantages aren't 
absolute, but rather things that depend on the exact situation at 
hand

Re: Optional type - how to correctly reset a wrapped immutable T

[jmh530 via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 13:51:20 UTC, jmh530 wrote:



How about:
[snip]


I can kind of like this more, but after re-reading your original 
post I'm not sure it really resolves your issue:


struct Optional(T) {
import std.traits : isMutable;
T[] bag;

this(T t) inout {
bag = [t];
}

void opAssign(T rhs)
{
static if (isMutable!T)
bag[0] = rhs;
else
bag = [rhs];
}
}

Optional!T optional(T)(T x)
{
return Optional!T(x);
}

void main()
{
int x = 3;
const(int) xx = 3;
immutable(int) xxx = 3;
immutable(int)  = 4;

auto y = optional(x);
auto yy = optional(xx);
auto yyy = optional(xxx);
yyy = ;
}

Re: CTFE ^^ (pow)

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 27 March 2018 at 02:23:50 UTC, Jonathan M Davis wrote:
I think that that we all agree that having these functions work 
with CTFE would be great. The disagreement is mostly on how 
much of an inconvenience it is or how big a deal that 
inconvenience is.


Ultimately, it's just a question of someone taking the time to 
do the work, not whether the work is desirable. And 
fortunately, it looks like at least some of those functions 
have had recent work done towards making them work in CTFE 
(e.g. the PR that Walter linked to in another post).


- Jonathan M Davis


That's great news!

Re: Optional type - how to correctly reset a wrapped immutable T

[SimonN via Digitalmars-d-learn]

On Monday, 26 March 2018 at 14:17:03 UTC, Jonathan M Davis wrote:
Rebindable does is pretty questionable as far as the type 
system goes, but it does what it does by forcing pointer 
semantics on a class reference, so the point is arguable.


Yeah, I've always assumed that Rebindable cannot be implemented 
without internally breaking the type system, then exposing a safe 
interface.


But this sparked my interest, I've dug out the Rebindable code:

private mixin template RebindableCommon(T, U, alias This)
if (is(T == class) || is(T == interface) || 
isAssociativeArray!T)

{
private union
{
T original; // e.g., immutable(A) for classs A
U stripped; // the unqualified type, e.g., A
}
// ...
}

Does Rebindable-using code, oblivious of the hacks inside 
Rebindable, remain 100 % safe even with aggressive compiler 
optimizations? For class A, inside Rebindable!(immutable A), 
there is a union of (immutable A) and A. I suspect that the D 
compiler is allowed to treat this reference to (immutable A) as 
immutable itself. Have there never been bugs here when, later, 
stripped = another.stripped;?


-- Simon

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[bachmeier via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast


Named parameter arguments is an advantage? I would not consider 
using a language with named parameter arguments. At best, 
claiming it's an advantage is arbitrary.


You might have better luck comparing the languages if you got rid 
of the +1/-1 thing.

[Issue 18670] New: compiler segfault if `new` on a union type with dip1000

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18670
   Summary: compiler segfault if `new` on a union type with
dip1000
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

Found while trying to compile Adam D. Ruppe's terminal-emulator, reduced with
dustmite and some manual work

% cat terminalemulator.d
void foo() {
new OVERLAPPED;
}

union OVERLAPPED {
uint OffsetHigh;
uint Pointer;
}
% gdb dmd
< ... blah blah ... >
(gdb) r terminalemulator.d -dip1000
< ... blah blah ... >
DMD v2.079.0-283-g2e21d0713-dirty DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x0059f2bd in dmd.escape.escapeByValue(dmd.expression.Expression,
dmd.escape.EscapeByResults*) (er=0x7ffeca60, e=0x0) at dmd/escape.d:1293
1293e.accept(v);
(gdb) bt
#0  0x0059f2bd in dmd.escape.escapeByValue(dmd.expression.Expression,
dmd.escape.EscapeByResults*) (er=0x7ffeca60, e=0x0) at dmd/escape.d:1293
#1  0x0059e4a9 in dmd.escape.checkNewEscape(dmd.dscope.Scope*,
dmd.expression.Expression, bool) (gag=false, e=0x0, sc=0x7e274120) at
dmd/escape.d:592
#2  0x005b8342 in ExpressionSemanticVisitor::visit(NewExp*)
(this=0x7ffecf08, exp=0x7f6b53b0) at dmd/expressionsem.d:2363
#3  0x005a9ba6 in NewExp::accept(Visitor*) (this=0x7f6b53b0,
v=0x7ffecf08) at dmd/expression.d:4155
#4  0x005cc5ef in expressionSemantic(Expression*, Scope*)
(e=0x7f6b53b0, sc=0x7e274120) at dmd/expressionsem.d:9367
#5  0x0064f0cc in StatementSemanticVisitor::visit(ExpStatement*)
(this=0x7ffecfd8, s=0x7f6b5420) at dmd/statementsem.d:177
#6  0x00631a0e in ExpStatement::accept(Visitor*) (this=0x7f6b5420,
v=0x7ffecfd8) at dmd/statement.d:715
#7  0x0064efa7 in statementSemantic(Statement*, Scope*)
(s=0x7f6b5420, sc=0x7e274120) at dmd/statementsem.d:126
#8  0x0064f38a in StatementSemanticVisitor::visit(CompoundStatement*)
(this=0x7ffed2d8, cs=0x7f6b5440) at dmd/statementsem.d:235
#9  0x00632206 in CompoundStatement::accept(Visitor*)
(this=0x7f6b5440, v=0x7ffed2d8) at dmd/statement.d:908
#10 0x0064efa7 in statementSemantic(Statement*, Scope*)
(s=0x7f6b5440, sc=0x7e274120) at dmd/statementsem.d:126
#11 0x00663aae in Semantic3Visitor::visit(FuncDeclaration*)
(this=0x7ffedb80, funcdecl=0x7f6b5060) at dmd/semantic3.d:581
#12 0x005d35e6 in FuncDeclaration::accept(Visitor*)
(this=0x7f6b5060, v=0x7ffedb80) at dmd/func.d:2277
#13 0x006623c5 in semantic3(Dsymbol*, Scope*) (dsym=0x7f6b5060,
sc=0x7e273e30) at dmd/semantic3.d:82
#14 0x006627c6 in Semantic3Visitor::visit(Module*)
(this=0x7ffedc30, mod=0x7f6b4c00) at dmd/semantic3.d:193
#15 0x0055838e in Module::accept(Visitor*) (this=0x7f6b4c00,
v=0x7ffedc30) at dmd/dmodule.d:1322
#16 0x006623c5 in semantic3(Dsymbol*, Scope*) (dsym=0x7f6b4c00,
sc=0x0) at dmd/semantic3.d:82
#17 0x005fd1f7 in dmd.mars.tryMain(ulong, const(char)**)
(argv=0x7ffee958, argc=3) at dmd/mars.d:836
#18 0x005fe17b in D main () at dmd/mars.d:1098

--

[Issue 18669] New: isNestedFunction does not check if parameter is a function

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18669
   Summary: isNestedFunction does not check if parameter is a
function
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

import std.traits;

class Outer
{
class Inner
{
}
}

void main()
{
void fun(int i);
int i;
struct SS
{
int bar() { return i; }
}
static assert(isNestedFunction!(fun));
static assert(isNestedFunction!(SS));
static assert(isNestedFunction!(Outer.Inner));
}

--

Re: DConf 2018 Hackathon -- now open to the public free of charge

[rikki cattermole via Digitalmars-d-announce]

On 28/03/2018 3:04 AM, Mike Parker wrote:
Yesterday, I made the announcement that the Hackathon would be open to 
anyone willing to pay $100 to get in. That idea has now been nixed. 
Instead, anyone can come in for the full day completely free. It's like 
a big Munich Meetup!


I was a little offended (from a community POV) that it wasn't free for all.

No matter, good news for all that can attend!

DConf 2018 Hackathon -- now open to the public free of charge

[Mike Parker via Digitalmars-d-announce]

Yesterday, I made the announcement that the Hackathon would be 
open to anyone willing to pay $100 to get in. That idea has now 
been nixed. Instead, anyone can come in for the full day 
completely free. It's like a big Munich Meetup!


So, if you are in the area and can't make the conference, now 
you've got even more reason to drop by the Hackathon. If you know 
someone in the area who might be interested, drop them a line 
about it and encourage them to go. The food provided is for 
registered attendees, so those coming in for the Hackathon will 
need to bring their own lunch, but other than that they have 
access to the entire day, from the opening talk to the time they 
kick us out.

Re: Optional type - how to correctly reset a wrapped immutable T

[jmh530 via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 13:02:50 UTC, aliak wrote:


Hmm, now that I'm explicitly trying to produce it, I feel I 
maybe using inout incorrectly?


struct Optional(T) {
T[] bag;
this(T t) {
bag = [t];
}
}

struct S {
Optional!(inout(int)) f() inout
{
return Optional!(inout(int))(3);
}
}

void main()
{
auto a = S().f;
}

Above gives: Error: variable 
`onlineapp.Optional!(inout(int)).Optional.bag` only parameters 
or stack based variables can be inout


Change inout to const e.g. and it's all good.


You may refer to the section on struct constructors. inout on a 
constructor serves as both a const and an immutable constructor. 
This would allow you to create mutable/const/immutable objects of 
whatever struct. The payload could have some different setting.


https://dlang.org/spec/struct.html#struct-constructor

How about:

struct Optional(T) {
T[] bag;
this(T t) {
bag = [t];
}
}

Optional!T optional(T)(T x)
{
return Optional!T(x);
}

void main()
{
int x = 3;
const(int) xx = 3;
immutable(int) xxx = 3;

auto y = optional(x);
auto yy = optional(xx);
auto yyy = optional(xxx);
}

ErupteD v2.0 + Vulkan v1.1 breaking changes and NEW transition strategy

[ParticlePeter via Digitalmars-d-announce]

The deprecated ErupteD was un-deprecated again. Version v2.0 
comes with Vulkan 1.1 support and breaking changes regarding its 
dependency mechanism. Details in the projects dub and github [0] 
pages.


Regarding [1]:
ErupteD-V1 will be destroyed, ErupteD-V2 continued to implement a 
valid automation and testing scenario. If this is in placed a 
transition will be reconsider.


Apologies for your inconveniences, lessons learned. Put less on 
the plate and decrease the gradient of the gradual transition.


[0] https://github.com/ParticlePeter/ErupteD
[1] 
https://forum.dlang.org/thread/ljuodxxxqocakcczw...@forum.dlang.org

Re: Building application with LDC and -flto=thin fails in link stage

[kinke via Digitalmars-d-learn]

On Monday, 26 March 2018 at 23:32:59 UTC, Nordlöw wrote:

forwarded as `-L-flto=thin` but still errors as


Which is wrong, it's not a ld command-line option (i.e., the `-L` 
prefix is wrong). I don't use dub though, so I don't know how to 
fix it.

Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/26/18 9:26 AM, Atila Neves wrote:

On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote:

On 3/22/18 6:59 AM, Atila Neves wrote:

Blog post:

https://atilanevesoncode.wordpress.com/

Atila


It's simple. Unittests in imported modules should not be visible. They 
should be compiled as if -unittest was not passed.


Even Walter and Andrei are supportive: 
https://github.com/dlang/dmd/pull/6375#issuecomment-373487247




That would completely break __traits(getUnitTests).


I'm sure we could find a way to keep the features here, 99.99% of the 
time, you don't care about, nor want to parse or semantic, an imported 
module's unit tests. Only specialized unit test frameworks care about 
this feature.


It could be as simple as, if you use __traits(getUnitTests, modulename) 
anywhere in a module, then that module is imported the traditional way. 
Or we could create a specialized "import unittest" syntax for this purpose.


I think we can have the best of both worlds, with the common case being 
preferred.


-Steve

Re: Optional type - how to correctly reset a wrapped immutable T

[aliak via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 11:57:28 UTC, jmh530 wrote:

On Tuesday, 27 March 2018 at 06:26:57 UTC, aliak wrote:

[snip]

By the by,  how come inout has to be stack based and 
const/immutable/mutable doesn't? Isn't inout just one of those 
depending on context?


Example?


Hmm, now that I'm explicitly trying to produce it, I feel I maybe 
using inout incorrectly?


struct Optional(T) {
T[] bag;
this(T t) {
bag = [t];
}
}

struct S {
Optional!(inout(int)) f() inout
{
return Optional!(inout(int))(3);
}
}

void main()
{
auto a = S().f;
}

Above gives: Error: variable 
`onlineapp.Optional!(inout(int)).Optional.bag` only parameters or 
stack based variables can be inout


Change inout to const e.g. and it's all good.