Re: Destructors vs. Finalizers

[Mike Parker via Digitalmars-d]

On Wednesday, 26 July 2017 at 09:29:15 UTC, Moritz Maxeiner wrote:


As class destructors (in contrast to class finalizers) are then 
called exclusively in a deterministic fashion, there's no 
reason to forbid them from allocating using the GC, so I don't 
think using the @nogc attribute would be appropriate; I would 
much rather see another attribute in the likes of @disable, 
e.g. @deterministic, so

---
~this() {}// Finalizer
~this() @nogc {}  // Finalizer
~this @deterministic {}   // Destructor
~this @nogc @deterministic {} // Destructor
}


Yeah, this brings with it more flexibility. I'd prefer to avoid 
adding a new attribute for it, but this looks more interesting.



When cleaning up, the GC will ensure that all destructors are 
run where they exist, followed by all finalizers.


Having the GC directly call destructors defeats the point of 
separating them from finalizers in the first place:


Indeed! Let's pretend I didn't write that.

Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

[Laeeth Isharc via Digitalmars-d-announce]

On Thursday, 20 July 2017 at 12:23:31 UTC, Mike wrote:
A few years ago I created a bare metal demo on an ARM Cortex-M4 
microcontroller entirely in D.  It was just a demonstration 
that one could do bare metal programming for microcontrollers 
in D without any dependencies on C or assembly.  It was also a 
proof of some ideas I had about leveraging compile-time 
features of D to generate highly-optimized code (both small and 
fast) for these resource constrained systems.  I hit a wall, 
however, with Issue 14758[0], and ultimately abandoned D for 
other alternatives.


Well, that issue was recently fixed in GDC [1].  In addition, 
he GDC developers did some work to reduce the number of phony 
stubs one had to add to the runtime to get a build [2], removed 
the "shared is volatile" hack, and implemented the 
`volatileLoad/Store` intrinsics so I no longer need to do 
volatile access in assembly.  So, I decided to give it another 
try, and updated that demo. You can see the results at 
https://github.com/JinShil/stm32f42_discovery_demo


Congratulations, Mike.

https://www.reddit.com/r/programming/comments/6pn31c/d_on_bare_metal_stm32f4_redux/

Could someone post to Hacker News?  I don't have enough rep for 
it to propagate.

[Issue 17694] traits compiles fails for property of property

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |INVALID

--- Comment #1 from Steven Schveighoffer  ---
Actually, the issue is that the thing you are checking isn't valid syntax.

For example:

TBounds.Margins.Left;

Error: need 'this' for 'Margins' of type '@property TBounds()'

What you need is either the typeof, or to use an instance instead of the type
itself:


mixin(`static assert(__traits(compiles, TButton.init.Margins.Left));`);
mixin(`static assert(__traits(compiles, typeof(TButton.Margins.Left)));`);

--

Re: static foreach is now in github master

[Laeeth Isharc via Digitalmars-d-announce]

On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu 
wrote:
For those who want to play with our new static foreach feature 
and are willing to take the steps to building their own dmd, 
the feature is now merged in master: 
https://github.com/dlang/dmd/pull/6760


Happy hacking!

Andrei


Maybe good subject for an AMA (though not many upvoted so far). 
It's pretty cool that it was added on an afternoon during the 
hackathon.


 
https://www.reddit.com/r/programming/comments/6pn257/static_foreach_added_to_d_compiler_nightly/


Could someone post to Hacker News - I don't have enough rep there 
for stories to propagate.


Can always post another story later on explaining the practical 
benefits of static foreach (good topic for a D blog post) - 
marketing is about repetition.

Re: Destructors vs. Finalizers

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 8:19 AM, Guillaume Piolat wrote:

On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
When cleaning up, the GC will ensure that all destructors are run 
where they exist, followed by all finalizers. And destroy would be 
changed to call rt_destruct instead of rt_finalize.


Thoughts?


I don't get the distinction between destructors and "finalizers" but 
imho the problem is very much that the GC is calling ~this.


In D, the difference is when the thing is called. If it's called 
deterministically, either by function or by the compiler, then you have 
a lot more flexibility. If it's by the GC, it can be out of order with 
regards to your members, it could be on a different thread than the one 
that owned it, etc.


Regarding the OP, I think we really should strive to have something to 
fix this issue.


A poor-mans distinction could be done by checking whether the GC is 
currently the one destroying (a flag is available, but isn't publicly 
accessible), though that could get expensive.


-Steve

Re: Destructors vs. Finalizers

[Mike Parker via Digitalmars-d]

On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat 
wrote:


I don't get the distinction between destructors and 
"finalizers" but imho the problem is very much that the GC is 
calling ~this.


Destructors are deterministic, finalizers are not. At least, 
that's how I understand the terms are commonly used.

[Issue 17694] New: traits compiles fails for property of property

[via Digitalmars-d-bugs]

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

  Issue ID: 17694
   Summary: traits compiles fails for property of property
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

While the first assertion works, the second assertion fails.
I expect it should work, as the statement "typeof(TButton.Margins.Left) l;"
works fine

class TButton
{
@property TBounds Margins() { return null; }
}

class TBounds
{
@property float Left() { return 0.0; }
}

void main()
{
  mixin(`static assert(__traits(compiles, TButton.Margins));`); // OK
  mixin(`static assert(__traits(compiles, TButton.Margins.Left));`); // FAILS
}

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 7:55 AM, Timon Gehr wrote:

On 26.07.2017 13:22, Steven Schveighoffer wrote:

On 7/26/17 6:01 AM, Timon Gehr wrote:

On 26.07.2017 03:09, Steven Schveighoffer wrote:

...
In other words, I think we can assume for any C functions that are 
passed pointers that dereference those pointers, passing null is 
safely going to segfault.


I'm not going to assume that.


Tell you what, when you find a D platform that this doesn't happen, > 
we can fix it with a version statement ;)




The burden of proof is on you, not me. You are advocating the C approach 
to memory safety.


They leave NULL dereferencing undefined because in some quirky old 
useless no-longer-existing hardware, it doesn't segfault.


Note that this is more implementation defined than undefined (in fact, I 
couldn't find it listed in the UB section at all in the C11 spec).


Look at Walter's response. I think D can simply only work with C 
implementations on platforms where null dereferencing segfaults and 
ignore the rest.


Walter, can we update the @safe spec to say that reading/writing data 
from the null page in C is required to generate a program crash for 
@safe to be valid? This can be an exception to the UB rule.


I just don't see the point of adding extra checks for null when the 
hardware already does it.


-Steve

Re: Destructors vs. Finalizers

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
When cleaning up, the GC will ensure that all destructors are 
run where they exist, followed by all finalizers. And destroy 
would be changed to call rt_destruct instead of rt_finalize.


Thoughts?


I don't get the distinction between destructors and "finalizers" 
but imho the problem is very much that the GC is calling ~this.

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 26.07.2017 13:22, Steven Schveighoffer wrote:

On 7/26/17 6:01 AM, Timon Gehr wrote:

On 26.07.2017 03:09, Steven Schveighoffer wrote:

...
In other words, I think we can assume for any C functions that are 
passed pointers that dereference those pointers, passing null is 
safely going to segfault.


I'm not going to assume that.


Tell you what, when you find a D platform that this doesn't happen, > we can 
fix it with a version statement ;)

-Steve


The burden of proof is on you, not me. You are advocating the C approach 
to memory safety.

Bug in File.byRecord ?

[closescreen via Digitalmars-d-learn]

I have a file with empty lines: 2,3 and 5,6

filename.csv (with linenumbers for better view in this message)
1>Joe,Carpenter,30
2>
3>
4>Fred,Blacksmith,40
5>
6>

Now, if I run:
rdmd 
--eval='"filename.csv".File.byRecord!(string,string,int)("%s,%s,%d").writeln'


It prints:

[Tuple!(string, string, int)("Joe", "Carpenter", 30),
 Tuple!(string, string, int)("Joe", "Carpenter", 30),
 Tuple!(string, string, int)("Joe", "Carpenter", 30),
 Tuple!(string, string, int)("Fred", "Blacksmith", 40),
 Tuple!(string, string, int)("Fred", "Blacksmith", 40),
 Tuple!(string, string, int)("Fred", "Blacksmith", 40)]

It happens because code in

https://github.com/dlang/phobos/blob/master/std/stdio.d#L297

not checks return value after call formattedRead.

Is this a bug? Or I not understand something?

[Issue 16416] Phobos std.uni out of date (should be updated to latest Unicode standard)

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com
   Assignee|nob...@puremagic.com|dmitry.o...@gmail.com

--

[Issue 17681] [Function setTimes] additional function touch(f)

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
I think a function setTimes(filename) or setTimesCurrent(filename) would be a
useful addition.

The setTimes function is cross platform and so is handy to use in platform
agnostic code. It would be nice to have support for this in there somehow.

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 6:01 AM, Timon Gehr wrote:

On 26.07.2017 03:09, Steven Schveighoffer wrote:

On 7/25/17 8:45 PM, Timon Gehr wrote:

...
What Moritz is saying is that the following implementation of fclose 
is correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 return go_wild_and_corrupt_all_the_memory();
 }else{
 return actually_close_the_file(stream);
 }
}


I think we can correctly assume no fclose implementations exist that 
do anything but access data pointed at by stream. Which means a 
segfault on every platform we support.


On platforms that may not segfault, you'd be on your own.

In other words, I think we can assume for any C functions that are 
passed pointers that dereference those pointers, passing null is 
safely going to segfault.


I'm not going to assume that.


Tell you what, when you find a D platform that this doesn't happen, we 
can fix it with a version statement ;)


-Steve

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 3:05 AM, Shachar Shemesh wrote:

On 25/07/17 18:26, Andrei Alexandrescu wrote:

(btw void[] doesn't work)


Can you expand on this point?

Shachar


Because anything casts to void[] implicitly.

e.g.:

void main() @safe
{
   int *[] arr = new int*[5];
   read(0, arr); // reading raw pointer data, shouldn't be allowed
}

-Steve

[Issue 17692] Filtering a struct instance's .tupleof loses contained this reference

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17690] [REG2.066.0] scope guards leak declarations

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--

[Issue 17690] [REG2.066.0] scope guards leak declarations

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|scope guards leak   |[REG2.066.0] scope guards
   |declarations|leak declarations
   Severity|normal  |regression

--- Comment #1 from Vladimir Panteleev  ---
The front-end accepts it without error.

This seems to be a regression.
Introduced in https://github.com/dlang/dmd/pull/3564

--

[Issue 17689] finally clause leaks declarations

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--

[Issue 17686] [REG2.075.0] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|[REG2.075] Covariant return |[REG2.075.0] Covariant
   |types doesn't work with |return types doesn't work
   |override in some cases  |with override in some cases

--

[Issue 17277] Member and aggregate alignment semantics

[via Digitalmars-d-bugs]

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

ki...@gmx.net changed:

   What|Removed |Added

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

--

[Issue 17686] [REG2.075] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
Please include the entire test case in the bug report itself.

Here it is:

interface INode
{
@property INode parentNode();
@property IDocument ownerDocument();
}
interface IDocument: INode {}
interface IEntityReference: INode {}

class DOMImplementation(T)
{
abstract class Node: INode
{
override
{
@property Node parentNode() { return null; }
@property Document ownerDocument() { return null; } 
}

@property bool readonly() { return true; }
}
abstract class NodeWithChildren: Node {}

class Document: NodeWithChildren, IDocument {}

class EntityReference: NodeWithChildren, IEntityReference
{
override
{
@property bool readonly() { return true; }
}
}

}

void main()
{
alias aaa = DOMImplementation!string;
}

--

[Issue 17685] DMD 2.060 regression: align is not respected for structs

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Vladimir Panteleev  ---
Yep, fixed by https://github.com/dlang/dmd/pull/6754.

*** This issue has been marked as a duplicate of issue 17277 ***

--

[Issue 17277] Member and aggregate alignment semantics

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au

--- Comment #2 from Vladimir Panteleev  ---
*** Issue 17685 has been marked as a duplicate of this issue. ***

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 26.07.2017 05:02, Walter Bright wrote:

On 7/25/2017 5:56 PM, Andrei Alexandrescu wrote:
I'd think that would be the case, but failed to find a fgetc 
implementation that mentions it's undefined for a null FILE*. Is there 
a link? Thx. -- Andrei


The documentation for DMC++ fgetc() is:

   https://digitalmars.com/rtl/stdio.html#fgetc

and says:

   "Returns the character just read on success, or EOF if end-of-file or 
a read error is encountered."


The implementation checks for fp being NULL and returns EOF if it is.


The C mindset is that this check is a waste of precious processing 
resources and morally wrong, as only a fool would pass NULL anyway, and 
fools deserve to get UB.

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 26.07.2017 02:56, Andrei Alexandrescu wrote:


What Moritz is saying is that the following implementation of fclose 
is correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 return go_wild_and_corrupt_all_the_memory();
 }else{
 return actually_close_the_file(stream);
 }
}


I'd think that would be the case, but failed to find a fgetc 
implementation that mentions it's undefined for a null FILE*. Is there a 
link? Thx. -- Andrei


It's implicit. In C, whenever you pass something that is outside the 
interface specification, you get UB. Also, in C, there is no way to get 
a segmentation fault except for UB, and fgetc(NULL) segfaults with glibc.

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 26.07.2017 03:09, Steven Schveighoffer wrote:

On 7/25/17 8:45 PM, Timon Gehr wrote:

...
What Moritz is saying is that the following implementation of fclose 
is correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 return go_wild_and_corrupt_all_the_memory();
 }else{
 return actually_close_the_file(stream);
 }
}


I think we can correctly assume no fclose implementations exist that do 
anything but access data pointed at by stream. Which means a segfault on 
every platform we support.


On platforms that may not segfault, you'd be on your own.

In other words, I think we can assume for any C functions that are 
passed pointers that dereference those pointers, passing null is safely 
going to segfault.


I'm not going to assume that.

[Issue 17684] [REG 2.062] `static alias this` bug or incomplete implementation?

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|`static alias this` bug or  |[REG 2.062] `static alias
   |incomplete implementation?  |this` bug or incomplete
   ||implementation?
   Severity|normal  |regression

--- Comment #1 from Vladimir Panteleev  ---
This worked in 2.061, and it looks like it was broken by accident. Marking as a
regression.

Introduced in https://github.com/dlang/dmd/pull/1434

--

Re: Why structs and classes instanciations are made differently ?

[Houdini via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 17:16:00 UTC, Kagamin wrote:

On Tuesday, 25 July 2017 at 15:56:45 UTC, Houdini wrote:
Yes, but it isn't the default way in C++ to do dynamic 
instanciation.


https://github.com/isocpp/CppCoreGuidelines this? It's only 2 
years old. The new operator predates it by decades.


I meant :

When you need to instantiate a class, you usually do :

MyClass a;

and not :

MyClass* a = new MyClass();

You're in a value model.

If you find anything in Cpp Guidelines against that, I am 
interested.

[Issue 17683] __traits compiles does not work with package.d

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Vladimir Panteleev  ---
Nothing to do with __traits(compiles).

fullyQualifiedName!Bar expands to "sub.m2.Bar".

That fully qualified names don't work with package modules is issue 11847.

*** This issue has been marked as a duplicate of issue 11847 ***

--

[Issue 11847] Importing "package.d" module causes qualified name lookup to fail for sub modules

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||an...@s-e-a-p.de

--- Comment #11 from Vladimir Panteleev  ---
*** Issue 17683 has been marked as a duplicate of this issue. ***

--

Re: [your code here] Pure RPN calculator

[Timon Gehr via Digitalmars-d]

On 26.07.2017 11:45, Timon Gehr wrote:

On 26.07.2017 04:37, Seb wrote:

On Tuesday, 25 July 2017 at 21:13:54 UTC, Max Haughton wrote:

Semi-Functional/pure RPN calculator: https://run.dlang.io/is/JGkBZx

This is probably too long, but it demonstrates the compiler enforced 
safety and purity (State is passed through the fold), while also 
showing off the higher level parts of Phobos (Use of fold).


Max, this is a great example!
However, as you noticed it's a bit long and in fact in its current 
state it wouldn't look good:


http://imgur.com/a/KwczM

If there's no chance to make it shorter,


import std.stdio, std.string, std.algorithm, std.conv;
void main(){
 readln.split.fold!((stack,op){
 switch(op){
 static foreach(c;"+-*/") case [c]:
 return stack[0..$-2]~mixin("stack[$-2] "~c~" stack[$-1]");
 default: return stack~op.to!real;
 }
 })((real[]).init).writeln;
}



(Sorry for the double post. Internet connection problem.)

Re: [your code here] Pure RPN calculator

[Timon Gehr via Digitalmars-d]

On 26.07.2017 04:37, Seb wrote:

On Tuesday, 25 July 2017 at 21:13:54 UTC, Max Haughton wrote:

Semi-Functional/pure RPN calculator: https://run.dlang.io/is/JGkBZx

This is probably too long, but it demonstrates the compiler enforced 
safety and purity (State is passed through the fold), while also 
showing off the higher level parts of Phobos (Use of fold).


Max, this is a great example!
However, as you noticed it's a bit long and in fact in its current state 
it wouldn't look good:


http://imgur.com/a/KwczM

If there's no chance to make it shorter,


import std.stdio, std.string, std.algorithm, std.conv;
void main(){
readln.split.fold!((stack,op){
switch(op){
static foreach(c;"+-*/") case [c]:
return stack[0..$-2]~mixin("stack[$-2] "~c~" stack[$-1]");
default: return stack~op.to!real;
}
})((real[]).init).writeln;
}

Re: [your code here] Pure RPN calculator

[Timon Gehr via Digitalmars-d]

On 26.07.2017 04:37, Seb wrote:

On Tuesday, 25 July 2017 at 21:13:54 UTC, Max Haughton wrote:

Semi-Functional/pure RPN calculator: https://run.dlang.io/is/JGkBZx

This is probably too long, but it demonstrates the compiler enforced 
safety and purity (State is passed through the fold), while also 
showing off the higher level parts of Phobos (Use of fold).


Max, this is a great example!
However, as you noticed it's a bit long and in fact in its current state 
it wouldn't look good:


http://imgur.com/a/KwczM

If there's no chance to make it shorter,


import std.stdio,std.string,std.algorithm,std.conv;
void main(){
readln.split.fold!((stack,op){
switch(op){
static foreach(c;"+-*/") case [c]:
return stack[0..$-2]~mixin("stack[$-2] "~c~" stack[$-1]");
default: return stack~op.to!real;
}
})((real[]).init).writeln;
}

[Issue 17681] [Function setTimes] additional function touch(f)

[via Digitalmars-d-bugs]

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

--- Comment #1 from Vladimir Panteleev  ---
The way to do this on Linux is to call utime(fileName, null).

(In reply to Martin Tschierschke from comment #0)
> The work around in the moment is to use execute("touch ~"filename").
> Not the right for a system programming language :-(

I think this is simpler:

utimes(fileName.toStringz, *cast(timeval[2]*)null);

Not sure whether this is something that comes up frequently enough to be in
Phobos, especially considering it seems rather platform-specific. The name
"touch" carries with it the possible implication that non-existing files will
be created (as done by the program), which might not be desirable for a Phobos
function.

--

[Issue 17686] [REG2.075] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

--- Comment #2 from Daniel Kozak  ---
introduced in this commit:
https://github.com/dlang/dmd/commit/fb315d03f0744b8406d31b9c106d3a42c0c178b3

--

[Issue 17458] [std.regex] Assertion failure in package.d

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/7a51c0e24eea6c02336d2aa897c608974ea2ac57
Fix issue 17458 add messages to asserts

https://github.com/dlang/phobos/commit/008a8a3ef3fab4e1f51f2bf65d3f6b42dc152f78
Merge pull request #5660 from DmitryOlshansky/issue-17458

[std.regex] Fix issue 17458 - add messages to asserts
merged-on-behalf-of: Stefan Koch 

--

[Issue 17680] Broken ddmd source links in documentation

[via Digitalmars-d-bugs]

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

--- Comment #2 from Vladimir Panteleev  ---
https://github.com/dlang/dmd/pull/7030

Pretty please file separate issues for separate issues next time!

--

Re: Destructors vs. Finalizers

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:
Regarding the issue with `destroy` not being @nogc, I my 
understanding is it comes down to `rt_finalize` not being 
@nogc. I haven't dug too deeply into the discussions around it, 
but I'm wondering if it's possible to separate the concept of 
destruction from finalization in the implementation?


Possible, yes, and I agree that separating destruction 
(deterministic end of object lifetime) and finalization (GC 
collection caused end of object lifetime) for classes is 
something we should do.




Externally, we can do it with the existing language:

class {
~this() {} // Finalizer

~this @nogc {} // Destructor
}


As class destructors (in contrast to class finalizers) are then 
called exclusively in a deterministic fashion, there's no reason 
to forbid them from allocating using the GC, so I don't think 
using the @nogc attribute would be appropriate; I would much 
rather see another attribute in the likes of @disable, e.g. 
@deterministic, so

---
~this() {}// Finalizer
~this() @nogc {}  // Finalizer
~this @deterministic {}   // Destructor
~this @nogc @deterministic {} // Destructor
}
---




Internally, the runtime will treat each differently. an 
rt_destruct would call all every __dtor in a hierarchy


As long as finalizers are then not part of __dtor.

and rt_finalize would be changed to call every __finalizer (a 
new addition) in a hierarchy.


When cleaning up, the GC will ensure that all destructors are 
run where they exist, followed by all finalizers.


Having the GC directly call destructors defeats the point of 
separating them from finalizers in the first place: If a 
destructor should be run on GC finalication, the finalizer must 
manually call the destructor (using e.g. `destroy`).
The GC must *never* call destructors automatically after 
splitting off finalizers, because that would turn destructors 
back into finalizers.


And destroy would be changed to call rt_destruct instead of 
rt_finalize.


Yes, that would then be the correct behaviour for `destroy`.

[Issue 17680] Broken ddmd source links in documentation

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17680] Broken ddmd source links in documentation

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/dlang/dlang.org/pull/1845

--

[Issue 17677] [REG 2.073.0] ICE when adding ulong to cfloat

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||ice
Summary|[Reg 2.073] ICE when adding |[REG 2.073.0] ICE when
   |ulong to cfloat |adding ulong to cfloat
 OS|Windows |All

--- Comment #1 from Vladimir Panteleev  ---
Introduced in https://github.com/dlang/dmd/pull/6238

--

Re: scope pointers in @safe code

[John Colvin via Digitalmars-d]

On Wednesday, 26 July 2017 at 08:20:42 UTC, Shachar Shemesh wrote:

void fn(scope int* var) @safe {
(*var)++;
}

void fn2() @safe {
int a;

fn();
}

The above program does not compile:
d.d(8): Error: cannot take address of local a in @safe function 
fn2


I propose that the scope keyword be activated to mean "I do not 
pass the pointer you gave me out of the function", which would 
make this code compile (as it should, as it is not doing 
anything unsafe).


Shachar


compile with -dip1000

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 06:44:51 UTC, Shachar Shemesh wrote:

On 25/07/17 18:29, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 14:39:15 UTC, Shachar Shemesh 
wrote:

On 25/07/17 17:24, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh 
wrote:

The title really does says it all.


Since you explicitly state *all* OS functions:
nothrow: Should be OK (only callbacks could violate this and 
they should be nothrow, anyway).
Technically, any system call that is a pthreads cancellation 
point may throw a C++ exception.


Good to know, then since D is supposed to be able to catch C++ 
exceptions (and can on 64bit Linux [1]) none of those may be 
attributed as `nothrow`, because C++ exceptions don't derive 
from `Error` >


If we go down that route, however, calling system calls from 
nothrow becomes completely impossible, which is another way 
of saying that decorating just about anything with nothrow 
becomes impossible.


No. `nothrow` functions can call throwing ones, as long as 
they catch any exceptions not derived from Error thrown by 
them.




And right there and then you've introduced a serious problem.
The purpose of the C++ exception thrown on cancellation point 
is to terminate the thread. It is designed to be uncatchable.


The issue lies with the definition of `nothrow` considering only 
D Throwables;
it would have to be updated to apply to C++ exceptions that 
equate to D exceptions derived from Error.




I think labeling these "nothrow" is the correct course of 
action.


Not with the `nothrow` spec as it is right now. After the spec 
having been updated to apply to C++ exception that may not be 
caught, sure.


I'm not sure this is the most compelling argument, however. 
The function passed to pthread_create does not, logically, 
run in the pthread_create function. As such, I don't think 
this logic holds.


Then the @nogc definition would need to be updated from: "or 
indirectly through functions it may call" to reflect this, 
because that can be interpreted both ways.




As for pthread_join, I have no idea what you meant by it. 
Please elaborate why you think it is a problem.


Possible scenario on single core (no hyperthreading) system:
- thread 1 spawns thread 2
- thread 1 enters @nogc function `foo` and calls 
`pthread_join` on thread 2 before its own timeslice is over 
(and thus enters blocked state)

- thread 2 does work allocating via the GC, then terminates
- thread 1 wakes up and leaves @nogc function `foo`

Because @nogc (in contrast to nothrow) is explicitly designed 
as transitive, logically speaking, `foo` violated its @nogc 
constraint (it *caused* the GC allocations in thread 2).


Following that logic, ANY function that might affect another 
thread cannot be @nogc.


Not any function; as I interpret the spec only those who manually 
interleave another thread allocating via the GC such that it 
looks to a caller as if they had allocated using the GC.


I think this way madness lies. I don't think other threads 
action, even if linked in some weird semantic way to ours, make 
us accountable to their actions.


I would say it depends on the exact semantics of each use case 
whether we are accountable.




If you pass a callback that is not @nogc to pthread_create, 
then your other thread might allocate. This doesn't change the 
fact that pthread_create doesn't allocate.


The "indirectly through functions it may call" of the @nogc spec 
is ambiguous here because it doesn't actually require a direct 
call chain to the allocation. It would need to be updated.


At Weka, we use this understanding of the semantics all the 
time. Our main thread is as @nogc as we can possibly make it. 
Whenever we need anything that violates our usual restrictions, 
we send it either to other threads or other processes for 
execution, and use the results when they return. Defining the 
various attributes too strictly will simply mean we cannot use 
them anywhere (which is pretty much what happens today, but the 
very thing I'm trying to change here).


There is a difference between what's sensible and what the 
current wording of the spec allows for and before it's OK to 
attribute functions where the ambiguity applies, the spec wording 
(for both @nogc and nothrow) has to be made unambiguous.


P.S.: In case it's not clear: I'm playing devil's advocate in 
this subthread.

[Issue 17693] std.json cannot parse dub.json package files

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
Fairly sure the JSON spec forbids trailing commas, so accepting them would
actually be violating the spec.

Although we could add an option to allow parsing trailing commas, it would make
much more sense to fix Dub instead.

Please file this at https://github.com/dlang/dub/issues ?

If you would like std.json to have an option to allow trailing commas, please
file a new issue, but I think it would need to have a much stronger
justification than just Dub allowing them.

As a workaround, I suggest that you use the same JSON parsing library in your
project that Dub uses. That should guarantee compatibility.

--

[Issue 17673] regex(["\\\\\\\\|\\\\\"", "\"|$"]) - wrong whichPattern

[via Digitalmars-d-bugs]

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

--- Comment #2 from Dmitry Olshansky  ---
(In reply to Dmitry Olshansky from comment #1)
> https://github.com/dlang/phobos/pull/5660

Sorry wrong window.

--

[Issue 17458] [std.regex] Assertion failure in package.d

[via Digitalmars-d-bugs]

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

--- Comment #3 from Dmitry Olshansky  ---
https://github.com/dlang/phobos/pull/5660

--

[Issue 17673] regex(["\\\\\\\\|\\\\\"", "\"|$"]) - wrong whichPattern

[via Digitalmars-d-bugs]

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

--- Comment #1 from Dmitry Olshansky  ---
https://github.com/dlang/phobos/pull/5660

--

[Issue 17693] New: std.json cannot parse dub.json package files

[via Digitalmars-d-bugs]

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

  Issue ID: 17693
   Summary: std.json cannot parse dub.json package files
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

It's only a minor issue but I want to bring this to your attention.

std.json cannot parse several dub.json files as the json implementation of dub
allows trailing commas. std.json will fail to parse these package definitions.

I noticed this (annoying) issue while writing an own dub registry server.

--

[Issue 17458] [std.regex] Assertion failure in package.d

[via Digitalmars-d-bugs]

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

--- Comment #2 from Vladimir Panteleev  ---
The error message needs to be improved, then. "Assertion failure" is devoid of
any information.

See also: https://github.com/dlang/phobos/pull/5578

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 00:35:13 UTC, Steven Schveighoffer 
wrote:

On 7/25/17 5:23 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer 
wrote:

The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) 
specific implementation detail (it's what you generally expect 
to happen, but AFAIK it isn't defined in official ISO/IEC C).


In cases where C does not crash when dereferencing null, then D 
would not crash when dereferencing null. [...]


OK, my (wrong) assumption was that a D compiler would on those 
platforms be required to inject null checks+crash in order to 
satisfy the property that null dereferences crashes D programs 
rely on.
Since that seems to not be the case: Is this documented in the D 
spec somewhere (I couldn't find it)? If not, imho it should.

[Issue 17458] [std.regex] Assertion failure in package.d

[via Digitalmars-d-bugs]

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

--- Comment #1 from Dmitry Olshansky  ---
Not a bug - there is no match, before calling matches.hit one must check it for
!matches.empty.

--

[Issue 17066] [REG2.073a] std.regex captures got immutable

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

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

--- Comment #6 from Dmitry Olshansky  ---
Regex was reverted

--

[Issue 17673] regex(["\\\\\\\\|\\\\\"", "\"|$"]) - wrong whichPattern

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|dmitry.o...@gmail.com

--

[Issue 17668] regex(q"<[^]>")

[via Digitalmars-d-bugs]

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

--- Comment #1 from Dmitry Olshansky  ---
https://github.com/dlang/phobos/pull/5657

--

scope pointers in @safe code

[Shachar Shemesh via Digitalmars-d]

void fn(scope int* var) @safe {
(*var)++;
}

void fn2() @safe {
int a;

fn();
}

The above program does not compile:
d.d(8): Error: cannot take address of local a in @safe function fn2

I propose that the scope keyword be activated to mean "I do not pass the 
pointer you gave me out of the function", which would make this code 
compile (as it should, as it is not doing anything unsafe).


Shachar

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[Olivier FAURE via Digitalmars-d]

On Tuesday, 25 July 2017 at 09:53:02 UTC, Mike Parker wrote:

On Tuesday, 25 July 2017 at 07:58:13 UTC, Olivier FAURE wrote:
I feel like making a list of alternative proposals and why 
they were rejected would still be a good idea, both to improve 
the quality of the debate in this thread (people are proposing 
alternative syntaxes that should be addressed in the DIP), and 
for posterity.


We weren't speaking of rejected proposals, but of previously 
reviewed drafts. Rejected proposals already include a summary 
of why they were rejected. You can a list of all DIPs submitted 
under the current process, including links and their current 
status, at:


https://github.com/dlang/DIPs/blob/master/DIPs/README.md


I... think you misunderstood me? I shouldn't have used the word 
'proposals', I should have said 'suggestions'.


What I meant was "I think it would be better for the current 
version of DIP 1009 to include a 'Rejected alternative syntaxes' 
that would include a summary of the previously discussed 
suggestions for improving contract readability."


MysticZach argues that such a section would be pointless since 
the language authors read the previous version of DIP 1009, but I 
still think adding it would be a good idea (for posterity and to 
streamline discussions in this thread).

Re: Crypto.lib and ssl.lib for Win32

[MGW via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 21:51:39 UTC, Adam D. Ruppe wrote:

On Tuesday, 25 July 2017 at 12:11:08 UTC, MGW wrote:
Where can I find the ready made for usage or how to create 
cryptro.lib and ssl.lib for Windows 32 that are necessary for 
my project?


Do you have the crypto.dll and ssl.dll? If so, implib can make 
the lib files. If you don't have implib, email the dlls to me 
and I'll get it to you (destructiona...@gmail.com)


Thank you for your offer!
I didn`t find crypto.dll and ssl.dll files for Win32 with the 
necessary list of export functions. but there`re files 
libssl32.dll and libeay32.dll (from OpenSSL for Windows) which 
have the necessary export functions. Can I use them instead of 
crypto.dll and ssl.dll? Is it possible to rename libssl32.dll to 
ssl.dll? One more question: Was the module http2.d check and did 
it operate in Win32?
I understand that it works in Linux but I really need it working 
in Win32.

Re: How to make autocompletion for IDE?

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 10:45:38 UTC, unDEFER wrote:

On Tuesday, 25 July 2017 at 10:35:14 UTC, Andrea Fontana wrote:

If you want to add UFCS suggestions to DCD it would be useful 
for your project and all other IDEs too!


Andrea


Thank you, I will think. But if it was easy, authors self would 
do it :-)


Did you try with [1]?

[1] http://forum.dlang.org/post/okktlu$2bin$1...@digitalmars.com

Redox + D

[Suliman via Digitalmars-d]

I think most of people have heard about https://redox-os.org It 
is pretty modern micro-kernel OS written in Rust. I am not Rust 
fan, but if it solve some low-level task and allow to build on 
top of it more hight-level tools why not to use it?


Now it have port of GCC, Python and some other languages. Few 
days ago I wrote to Michael Aaron Murphy, man who did port of GCC 
and asked him about D. Here is his answer:


"I wouldn't count out Rust as being too low level, as it has a 
lot of high level abstractions, and crates to provide even higher 
level abstractions for more specific fields. That said, when 
Redox becomes self-hosting, it should be capable of running any 
software that depends on libc, D included"

Re: all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

On 25/07/17 18:26, Andrei Alexandrescu wrote:

(btw void[] doesn't work)


Can you expand on this point?

Shachar

Re: Is there a way to use x86 and x86_mscoff with dub simultaneously.

[Jacob Carlborg via Digitalmars-d]

On 2017-07-26 00:41, Sönke Ludwig wrote:


What you can do is to create a configuration that only works for x86_64:

 name "myproject"

 configuration "library" {
 platforms "x86_64"
 targetType "library"
 // ...
 }

This will cause the configuration resolution to fail if the wrong 
architecture is selected. The downside is that I think the error message 
will not be very helpful currently (something like "could not resolve 
configuration for myproject"), but that should be fixable.


It needs to work for 32bit as well. But for 32bit it would only work 
with COFF.


--
/Jacob Carlborg

[Issue 15432] Win64: bad code offset in debug line number info

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 15432] Win64: bad code offset in debug line number info

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/399b12d8d6feaf43ced88c2559404f29ab70c496
fix issue 15432: Win64: bad code offset in debug line number info

pinhole optimization should not yield different results if run twice

https://github.com/dlang/dmd/commit/a7867ca72bf51a6db9e3ed44428e142a21d3de75
Merge pull request #6979 from rainers/issue15432

fix issue 15432: Win64: bad code offset in debug line number info
merged-on-behalf-of: Rainer Schuetze 

--

Re: Cast to subclass in the dmd compiler

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-07-25 23:06, unDEFER wrote:

I have found the answer in the code.
Right code is:

Import imp = m.isImport();
if (imp !is null)

Thank you.


That's the correct solution. For Expression, there's a field called "op" 
that indicates what kind of expression it is, which can used in 
combination with a cast.


--
/Jacob Carlborg

Re: Get UDA of unit tests during Runtime.moduleUnitTester

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-07-26 05:27, Matthew Remmel wrote:

So as mentioned above, the first problem is that using 
ModuleInfo.unitTest returns an aggregated function of all 3 unit tests 
for that module, instead of each one individually, so the UDA 
information is lost. The second problem is that running 
__traits(getUnitTests, app) only returns the 2 tests at module scope, 
and not the one nested inside Foo.


Unless you want to go with the approach Seb suggested, using 
unit-threaded, you need to recursively iterate the module to get all 
aggregates using __traits(allMembers) then use __traits(getUnitTests) 
for each aggregate to get all unit tests.


Even then, I haven't been able to 
figure out how to dynamically get the module symbol to pass to __traits 
inside of the Runtime.moduleUnitTester function.


That's not possible, the UDAs are lost after compile time. Also, all the 
unit tests block are combined into one function per module, which is 
what Runtime.moduleUnitTester is running. The separate unit test blocks 
are gone at runtime so there's nothing to connect the UDAs to.


--
/Jacob Carlborg

Re: all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

On 25/07/17 18:29, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 14:39:15 UTC, Shachar Shemesh wrote:

On 25/07/17 17:24, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:

The title really does says it all.


Since you explicitly state *all* OS functions:
nothrow: Should be OK (only callbacks could violate this and they 
should be nothrow, anyway).
Technically, any system call that is a pthreads cancellation point may 
throw a C++ exception.


Good to know, then since D is supposed to be able to catch C++ 
exceptions (and can on 64bit Linux [1]) none of those may be attributed 
as `nothrow`, because C++ exceptions don't derive from `Error` >


If we go down that route, however, calling system calls from nothrow 
becomes completely impossible, which is another way of saying that 
decorating just about anything with nothrow becomes impossible.


No. `nothrow` functions can call throwing ones, as long as they catch 
any exceptions not derived from Error thrown by them.




And right there and then you've introduced a serious problem. The 
purpose of the C++ exception thrown on cancellation point is to 
terminate the thread. It is designed to be uncatchable.


Had that been D, it might derive from Error, or even directly from 
Throwable. This is C++, however. It some weirdly named class.


I think labeling these "nothrow" is the correct course of action.

The decoration's situation with callbacks is pretty horrible 
throughout D.


Do you mean throughout druntime and phobos?


I'm rechecking what I mean. I may have misspoke.



I'm not sure this is the most compelling argument, however. The 
function passed to pthread_create does not, logically, run in the 
pthread_create function. As such, I don't think this logic holds.


Then the @nogc definition would need to be updated from: "or indirectly 
through functions it may call" to reflect this, because that can be 
interpreted both ways.




As for pthread_join, I have no idea what you meant by it. Please 
elaborate why you think it is a problem.


Possible scenario on single core (no hyperthreading) system:
- thread 1 spawns thread 2
- thread 1 enters @nogc function `foo` and calls `pthread_join` on 
thread 2 before its own timeslice is over (and thus enters blocked state)

- thread 2 does work allocating via the GC, then terminates
- thread 1 wakes up and leaves @nogc function `foo`

Because @nogc (in contrast to nothrow) is explicitly designed as 
transitive, logically speaking, `foo` violated its @nogc constraint (it 
*caused* the GC allocations in thread 2).


Following that logic, ANY function that might affect another thread 
cannot be @nogc. I think this way madness lies. I don't think other 
threads action, even if linked in some weird semantic way to ours, make 
us accountable to their actions.


If you pass a callback that is not @nogc to pthread_create, then your 
other thread might allocate. This doesn't change the fact that 
pthread_create doesn't allocate.


At Weka, we use this understanding of the semantics all the time. Our 
main thread is as @nogc as we can possibly make it. Whenever we need 
anything that violates our usual restrictions, we send it either to 
other threads or other processes for execution, and use the results when 
they return. Defining the various attributes too strictly will simply 
mean we cannot use them anywhere (which is pretty much what happens 
today, but the very thing I'm trying to change here).


Shachar

Re: D easily overlooked?

[Bienlein via Digitalmars-d]

When looking at other language ranking sites, D always scores 
better then Rust. Yet, Rust gets included in the ranking but D 
is ... nowhere to be seen.


Well, on the Tiobe index D is currently on place 23 way ahead of 
Lua, Scala, Rust, Kotlin, Groovy. So there is obviously 
asomething wrong with the Tiobe index here as all those other 
languagse are quite a bit in use. Hope this compensates a bit for 
your pain ;-).


Not to be a downer but D really in my eyes is missing that 
"unique" feature that people care about, that allows people to 
blog about the language...


D is the most feature rich language I know of. Maybe only Scala 
comes close, but Scala can be at times an unreadable mess as the 
designers of the language valued mixing functional and OO higher 
than readability. D, on the contrary, has a very clean design 
througout.


But you are right. D is missing some unique selling point like 
ease of concurrency using Communicating Sequential Processes in 
Go or memory safety in Rust without a GC. This is because D does 
not have a business model, but seems to be seen as a playground 
for building the greatest language ever. I fear this will not 
change. Topics of people arguing that D needs a business case pop 
up regularly here and are every time mostly or also completely 
ignored. It does not look like this will change, because the main 
drivers of the language never drop a comment in those discussions.

[Issue 17692] New: Filtering a struct instance's .tupleof loses contained this reference

[via Digitalmars-d-bugs]

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

  Issue ID: 17692
   Summary: Filtering a struct instance's .tupleof loses contained
this reference
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: htven...@gmail.com

Okay, let's start with the code to reproduce, to put things in context:

-

import std.meta : Filter;
import std.typecons : No;
import std.traits : hasUDA;

struct S
{
  int a;
  int b;
  @(No.Wanted) int c;
}

private template isWanted(alias field) {
  enum isWanted = !hasUDA!(field, No.Wanted);
}

void foo(TS...)(TS args)
{
  import std.conv : to;
  import std.stdio : writefln;

  foreach (index, arg; args)
  {
writefln("%d: %s", index, arg.to!string);
  }
}

void main()
{
  S s = S(5, 6, 7);
  foo(s.tupleof); // works, passes all struct fields as arguments
  foo(Filter!(isWanted, s.tupleof)); // error
}

-

EXPECTED BEHAVIOR

The both calls to foo() work, and the program outputs:
0: 5
1: 6
2: 7
0: 5
1: 6


ACTUAL BEHAVIOR

Compilation fails with the following errors:

tupleof_filter.d(31): Error: need 'this' for 'a' of type 'int'
tupleof_filter.d(31): Error: need 'this' for 'b' of type 'int'


REAL WORLD CASE

I hit this while working on https://github.com/trishume/ddbus/pull/21,
specifically when trying to allow selective marshaling of struct fields. I
changed
https://github.com/thaven/ddbus/blob/6bce6cf6490ce819f048b7ea8f1458ec66fbf1c8/source/ddbus/conv.d#L119
(which worked) from

buildIter(, arg.tupleof);

to

buildIter(, Filter!(isAllowedField, arg.tupleof));

and added the isAllowedField predicate template and then got the 'no this for
member' errors. I needed to rewrite this nice compact line of code into ugly
`foreach` + `static if` to work around the issue.

--