[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

Basile B.  changed:

   What|Removed |Added

 CC||turkey...@gmail.com

--- Comment #18 from Basile B.  ---
*** Issue 18878 has been marked as a duplicate of this issue. ***

--

[Issue 18878] Short-circuiting && not behaving correctly

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

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

Basile B.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |DUPLICATE

--- Comment #1 from Basile B.  ---
A fix is on the PR stack.

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

--

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[KingJoffrey via Digitalmars-d]

On Sunday, 20 May 2018 at 03:13:12 UTC, Neia Neutuladh wrote:


While it's mildly refreshing that you found something new to 
talk about, it would be nice if you found something productive 
to say. You're merely complaining that a person who has spent 
about two decades on D (for free), who has decades more 
experience with compilers, who is the main contributor to the D 
compiler, and who has a track record of being right a lot, is 
influential when it comes to changes to the language.


da da dah da dah dah dah da



Think of it this way.. that I'm injecting some quantum 
fluctuations into the D universe, in the hope that it triggers an 
inflationary period - otherwise the D universe will fizzle and 
die...


Creating another universe from scratch, is a long drawn out 
process..who want's to sit around for that to happen?

Re: is ==

[IntegratedDimensions via Digitalmars-d-learn]

Furthermore:

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

Shows real problems. You argue from the side that the bug already 
exists so we must work around it because we can't go back and 
"fix things". Who says? D has had breaking changes in the past so 
it is not a deal breaker. It is also a relatively easy transition 
because == null is very easy to find and fix.


With the mentality that one must always deal with introduced 
logic bugs that, if fixed, will break old code is insane. The 
whole point of fixing bugs is to make things work *correctly*.


The fact is someone decided it was a good idea to conflate null 
with some dynamic array BS and that is where all the problems 
come from. It should have never been done and this issue will 
persist until someone gets the balls to fix it.


After all, how do you know it won't actually make a lot of 
"buggy" code better?

Re: Can I infer the type from this?

[Dr.No via Digitalmars-d-learn]

On Sunday, 20 May 2018 at 02:01:20 UTC, Alex wrote:

On Sunday, 20 May 2018 at 01:41:03 UTC, Dr.No wrote:
I'd like to pass a symbol as paramater (class static member0 
and at same time get the type of this, something like this:


template myTemp(alias s)
{
enum myTemp = templateFunction!(??)(s.stringof);
}

the templateFunction has this signature:

int templateFunction(T)(string targetMembername)

but I don't how to get the type name from the give symbol name 
in myTemp. Can I make this work?


Something like this?

´´´
import std.stdio;

void main()
{
size_t s;
auto res = myTemp!s;
}


template myTemp(alias s)
{
enum myTemp = templateFunction!(typeof(s))(s.stringof);
}


int templateFunction(T)(string targetMembername)
{
static assert(is(T == size_t));
assert(targetMembername == "s");
return 42;
}
´´´


Oh, my bad: I totally forgot a crucial thing on question: I want 
this to work with a static member, for example, call myTemp like 
this myTemp!(C.a) I don't mind if I to pass the type as parameter 
somehow, like myTemp!(C, C.a) or myTemp!(C)(C.a) but I do need to 
pass a symbol as parameter, hence I'm using alias template 
parameter.

Re: is ==

[IntegratedDimensions via Digitalmars-d-learn]

On Sunday, 20 May 2018 at 02:09:47 UTC, Jonathan M Davis wrote:
On Sunday, May 20, 2018 01:51:50 IntegratedDimensions via 
Digitalmars-d- learn wrote:

Simply require == null as is null and be done with it.


That would be flat out wrong for dynamic arrays, because then

auto result = arr == null

and

int[] nullArr;
auto result = arr == nullArr;

would have different semantics. The way that dynamic arrays are 
designed to work even if they're null mucks with this 
considerably here.




Do you not see they are different?

You think

arr == nullArr

and

arr == null

are suppose to necessarily be the same semantics? That is 
patently false! You should rethink your position on that because 
it is wrong. null is a keyword in D and has a very special 
meaning and hence that meaning MUST be taken in to account.


There is no harm in making them different. Your logic thinks that 
that they should be the same but if you are wrong then your whole 
argument is wrong.


for example,

Object o = null;

then

o == null

should not be true even though "null == null" in some sense.

== null is a test of validity. One never checks if null == null 
and it is a meaningless case so allowing it as a possibility is 
meaningless.



You are treating null as if it is on the same level as objects 
and arrays and it is not. By doing so you lose the power of it 
being singled out as a keyword.



You can't police programmers minds and get them to program 
correctly.


That's true, but making things that are highly likely to be 
wrong illegal prevents bugs. e.g.


Not necessarily because you just create more bugs by doing that. 
Your son, the bubble boy, then does not develop an immune system 
that he should of developed by you trying to protect them from 
hurting himself.


You should get out of the business of trying to prevent things 
that you don't even know are going to happen. It is a bad mindset 
to be in because, for all you know, those things will never 
happen. Time is better spent than trying to police everyone from 
doing anything wrong. 1. You can't do it. 2. You make things 
worse in the long run because who's policing you to keep you from 
screwing up?


Do you know how many "bugs" are produced by people who are fixing 
"bugs"? We can surely bet more than zero.



while(cond);

is illegal in D precisely because it's error-prone. There are 
cases where doing something like that would be perfectly 
correct. e.g.


while(++a != b);

but you can do the exact same thing with empty parens

while(++a != b) {}

and all of those bugs with accidentally closing a loop with a 
semicolon go away, and you don't lose any expressiveness. The 
compiler just forces you to write it in a way that's far less 
error-prone.


This is a different problem and therefor not applicable.

Making it illegal to compare the null literal with == also 
prevents bug, and you don't lose any expressiveness doing it 
either. It's the same kind of logic. Making error-prone 
constructs illegal when there's a simple equivalent that isn't 
error-prone is good language design, because it prevents bugs 
without actually restricting the programmer. It's when the 
language starts disallowing things that aren't error-prone 
and/or don't have simple equivalents that you start running 
into problems with the compiler getting in your way and 
treating you like a kid. For simple stuff like this, it 
ultimately saves you time and effort without getting in your 
way. At most, you occasionally have to replace foo == null with 
foo is null or foo.length != 0, and it potentially saves you 
hours of effort tracking down a subtle bug.


- Jonathan M Davis


You certainly do lose expressiveness. You loose elegance because 
you cannot express logically related things in a logically 
related way.


The problem is the WHOLE reason it is error prone is from who 
ever decided the dynamic array syntax of == null would not 
compare it the same way it does everything else.


Basically someone thought they were going to be fancy and treat 
== null as the same as an allocated 0 length array. That was the 
problem from the get go.


== null should have a very specific and consistent meaning and 
someone decided to change that in an irregular and inconsistent 
meaning and now we have less elegance in the language than we 
could.


The reason why you are saying it is buggy is PRECISELY because of 
what was done wrong. Programmers assume that == null means the 
same thing it does everywhere else, but LO AND BEHOLD! Not in 
that one special case and if they don't know about that special 
case they hit the "bug".


See, what you call bugs is really the programmers failing to know 
the special case that was created. The special case that really 
had no reason to be a special case. So, in fact, who ever decided 
on the rules here created more problems than they solved.


Any time you create special cases you create complexity and that 
is what creates bugs of the type here. These bugs are 

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[Neia Neutuladh via Digitalmars-d]

On Sunday, 20 May 2018 at 02:53:10 UTC, KingJoffrey wrote:

On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:


As I understand it, in general, Walter is against doing ...


All I ever hear, is walter walter walter


While it's mildly refreshing that you found something new to talk 
about, it would be nice if you found something productive to say. 
You're merely complaining that a person who has spent about two 
decades on D (for free), who has decades more experience with 
compilers, who is the main contributor to the D compiler, and who 
has a track record of being right a lot, is influential when it 
comes to changes to the language.


This is social influence. Jonathan M Davis cited Walter's 
previous complaint because we generally care what Walter thinks, 
because we respect him. We won't always agree, but he usually has 
a decent reason for holding a position regarding compilers and 
programming languages.


If this bothers you, make your own language. You might not want 
to design it yourself, lest you fall into the same trap. Maybe 
you can find a committee? Or use a random number generator to 
design it?

Re: Override member variables

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 18:09:56 UTC, Gheorghe Gabriel wrote:

And of course, you cannot override private members.


wtf!

what do you mean we cannot override private members!

that's at the core of D!

what's with you anyway!

(ohh. to those new to the forums, that's friendly sarcasm, cause 
as you know, we're all friends in D - whether you like it or not).

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[KingJoffrey via Digitalmars-d]

On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:


As I understand it, in general, Walter is against doing ...


All I ever hear, is walter walter walter

mmm..takes me back to my childhood..

https://www.youtube.com/watch?v=-yZHveWFvqM

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:


If you have
sealed class A {
   private {
   // members
   }
}
Then you can't use the defualt 'private' if you need it for a 
specific member.


But if sealed is an access type of a member, 99% you will use 
sealed insted private in a class, so it is not redundant.


class A {
   sealed {
   // members
   }
   private int friendMember;
}

And you use private keyword only if you need to access that 
variable from a class/function/struct.. in the same module, 
like a friend.


I agree. But then we end up with what D should have implemented 
in the first place - C++ friends ;-)


(and in fact, quality software development should rarely, if 
ever, require the use of friend (which is just a managed way of 
breaking encapsulation - but, its managed, and managed by the 
programmer explicitly).


But in D, everything is your friend - you don't get to manage 
anything - which even to the dumbest of us, must suggest some 
impact on the quality of the software that will get developed in 
D. So, now, we need to consider absurd coding standards to get 
around this facebook style friendship problem (like implementing 
the proposed 'one class per module' crap - and btw. that is the 
purest form of OOP - so D actually forces you into this purest 
form of OOP - even other mainstream OOP langauges don't force 
that on you).


There is absolutely no reason why D cannot have both (the current 
way D does it, and the C++ way). It's obviously technically 
possible. It's obvious it would attract a great deal more 
programmers to D. It doesn't really complicate the language at 
all - that's just an excuse not to change. And, it's obvious, 
that protecting the interface would result in better quality 
software. It's a core fundamental principle of quality software.


It's just a matter of getting more diverse people into the D 
'community'.


But I get the feeling that's not what most D people want. The 
status quo is pretty comfortable for many, it seems.


Maybe in decade time, if/when D v3 comes out. But I won't be 
holding my breath.

[Issue 14086] Invalid extern C++ name for constructor / destructor

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

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

Manu  changed:

   What|Removed |Added

 CC||turkey...@gmail.com

--- Comment #2 from Manu  ---
I use pragma(mangle) to force the mangle for ctors to link to C++ ctor's just
fine... in what way is the ABI incompatible?

--

Re: auto: useful, annoying or bad practice?

[Neia Neutuladh via Digitalmars-d]

On Sunday, 20 May 2018 at 00:44:13 UTC, I love Ice Cream wrote:
Which brings me to where it probably is not a good place for 
it...in the return fadeclaration of a function/method. I'm very 
close to saying, even after having read some of the comments 
that try justifying it, that 100% of the time you want to 
specify the return type. When you create a function that 
returns something, you are actively deciding 'I need to return 
this thing, this is useful or the point of this function'. To 
not have that thing obviously spelled out in the API is a huge 
design mistake. Not only do you take away a self-documenting 
part of you function definition, you make someone have to 
either have a good IDE (which some people are adverse to using) 
or actually go read the source code. To not put the effort into 
thinking about the type (or constraints on the type when 
dealing with generic/templated code) is just lazy. And worse, 
it will facilitate libraries where people didn't think about 
their API as much as they should.


The return type for range-oriented functions in std.algorithm is 
usually not terribly useful. You get a range whose capabilities 
depend on the type of range you pass in, so you have to read the 
source code in any case. But at least listing the actual return 
type lets you skip some reading.


This design by introspection stuff is powerful, but it's 
unfriendly toward people trying to understand your code.


D is very hard to make an IDE for that would actually tell you 
what type the return value is. `pragma(msg, typeof(foo))` is 
probably your best bet, and that's kind of terrible.


Oh, there's also one other use of `auto` return types that I 
haven't seen mentioned before: it functions as a DMD pragma to 
include the function in generated .di files. Wretched, no?

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:

On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
If class level protection is added, please do not call it 
sealed.
People from c++ might be suprised by 'private' already. We do 
not have to confuse those c#ies too.


I thought the same.


Module level protection is enough to hide implementation 
details though. So while i do understand why you want this in 
D, i don't think it is worth it to complicate the language for 
something you can work around easily by putting the classes in 
their own modules.


I wouldn't consider putting classes into own modules a 
workaround. In my opinion it's more or less the solution.


Requiring such a restrictive 'solution', just to protect your 
interface from human error, is a solution for some, and not 
others.


open your mind a little.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 17:15:45 UTC, Neia Neutuladh wrote:

On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:

On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:


The point was encapsulation as you defined it was broken. 
private members were directly modified outside their class. 
In your words, everyone was a friend.


This is why we have coding standards ;-)

https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2017/april/accessing-private-fields-outside-of-classes-in-java.pdf


Coding standards are good enough for Java but not for D?


Coding standards are required for any quality development.

How many in the D community have, let alone follow, coding 
standards when coding in D?


The problem with D, is that everything is essentially unsafe, by 
default.


To get safety, you have to implement a variety of coding 
standards, that are simply not required as much in other 
mainstream langauges. The worst for me, is that you have to 
implement 'a one class per module coding standard' (because 
otherwise your privates just suddenly morph into public), just to 
ensure the safety of your interface from human error. That's 
crazy!


In any case...development is moving towards safer langauges, and 
towards safer by default.


D has a lot to catch up with, cause other langauges are decades 
ahead here.


That's why I see D has this little boutique langauges, for 
programmers that just want to get away with doing whatever - by 
default.

[Issue 18883] New: Revert workarounds expediting conversion of backend to D

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

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

  Issue ID: 18883
   Summary: Revert workarounds expediting conversion of backend to
D
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: slavo5...@yahoo.com

At the time the following PRs were created, the host compiler 2.068.2 (I
believe).  It had mangling issues that prevented conversion of the DMD backend
to D.  Therefore, Walter, insisted on a number of workarounds to expedite
conversion of the backed to D without having to wait for an updated host
compiler.  These workarounds should eventually be reverted (at least those that
still remain after the conversion).

https://github.com/dlang/dmd/pull/7416
-- See also https://github.com/dlang/dmd/pull/7505

https://github.com/dlang/dmd/pull/7523

https://github.com/dlang/dmd/pull/8249

--

Re: is ==

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, May 20, 2018 01:51:50 IntegratedDimensions via Digitalmars-d-
learn wrote:
> Simply require == null as is null and be done with it.

That would be flat out wrong for dynamic arrays, because then

auto result = arr == null

and

int[] nullArr;
auto result = arr == nullArr;

would have different semantics. The way that dynamic arrays are designed to
work even if they're null mucks with this considerably here.

> You can't police programmers minds and get them to program correctly.

That's true, but making things that are highly likely to be wrong illegal
prevents bugs. e.g.

while(cond);

is illegal in D precisely because it's error-prone. There are cases where
doing something like that would be perfectly correct. e.g.

while(++a != b);

but you can do the exact same thing with empty parens

while(++a != b) {}

and all of those bugs with accidentally closing a loop with a semicolon go
away, and you don't lose any expressiveness. The compiler just forces you to
write it in a way that's far less error-prone.

Making it illegal to compare the null literal with == also prevents bug, and
you don't lose any expressiveness doing it either. It's the same kind of
logic. Making error-prone constructs illegal when there's a simple
equivalent that isn't error-prone is good language design, because it
prevents bugs without actually restricting the programmer. It's when the
language starts disallowing things that aren't error-prone and/or don't have
simple equivalents that you start running into problems with the compiler
getting in your way and treating you like a kid. For simple stuff like this,
it ultimately saves you time and effort without getting in your way. At
most, you occasionally have to replace foo == null with foo is null or
foo.length != 0, and it potentially saves you hours of effort tracking down
a subtle bug.

- Jonathan M Davis

[Issue 18882] __gshared not displaying in debuginfo

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

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

--- Comment #1 from Manu  ---
Perhaps it's the extern(C++) that's the problem?

That would explain why I have debug problems a lot.

--

[Issue 18882] __gshared not displaying in debuginfo

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

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

Manu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|r.sagita...@gmx.de

--

[Issue 18882] New: __gshared not displaying in debuginfo

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

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

  Issue ID: 18882
   Summary: __gshared not displaying in debuginfo
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

In DMD, put a breakpoint somewhere at the top of mars.d: tryMain()
This function refers to `global` frequently, eg `global.params`,
`global.inifilename`, etc.
Notice that the debuginfo seems to be missing for `global`, the debugger just
says "Symbol not found", and you can't inspect the members.

I've seen this problem a lot, but this is a very convenient repro in a popular
codebase :)

--

Re: Can I infer the type from this?

[Alex via Digitalmars-d-learn]

On Sunday, 20 May 2018 at 01:41:03 UTC, Dr.No wrote:
I'd like to pass a symbol as paramater (class static member0 
and at same time get the type of this, something like this:


template myTemp(alias s)
{
enum myTemp = templateFunction!(??)(s.stringof);
}

the templateFunction has this signature:

int templateFunction(T)(string targetMembername)

but I don't how to get the type name from the give symbol name 
in myTemp. Can I make this work?


Something like this?

´´´
import std.stdio;

void main()
{
size_t s;
auto res = myTemp!s;
}


template myTemp(alias s)
{
enum myTemp = templateFunction!(typeof(s))(s.stringof);
}


int templateFunction(T)(string targetMembername)
{
static assert(is(T == size_t));
assert(targetMembername == "s");
return 42;
}
´´´

Re: is ==

[IntegratedDimensions via Digitalmars-d-learn]

On Sunday, 20 May 2018 at 00:19:28 UTC, Jonathan M Davis wrote:
On Saturday, May 19, 2018 17:50:50 IntegratedDimensions via 
Digitalmars-d- learn wrote:
So, ultimately what I feels like is that you are actually 
arguing for == null to be interpreted as is null but you don't 
realize it yet.


Not really, no. Having

foo == null

be rewritten to

foo is null

in the non-dynamic array cases should be fine except for the 
fact that it's then a terrible habit to be in when you then 
have to deal with dynamic arrays. Using


foo == null

with dyanmic arrays is an enormous code smell, because the odds 
are extemely high that the programmer thinks that they're 
checking if the dynamic array is null when that's not what 
they're doing at all. IMHO, it should definitely be an error to 
use == with null and dynamic arrays because it is such a big 
code smell. Either the code should be using is to check whether 
the array is null, or it should be checking length. It should 
never be using == with null.


But unfortunately, the compiler is completely backwards about 
this and treats it as an error with pointers and references but 
allows it with dynamic arrays. If the compiler were improved to 
just replace == with is in the cases that it currently treats 
as illegal, then that would be fine if it then treated it as 
illegal with dynamic arrays. But as it stands, it is still more 
efficient to use is with call references, so encouraging the 
programmer to use is is benefical, and it encourages the 
programmer to get in the habit of not using == with null, since 
it's a terrible habit to be in with dynamic arrays. But 
actually making it illegal for dynamic arrays would be a much 
better approach.


If it were up to me, it would just be illgal to use == with 
null in general, because that's really the way it should be 
with dynamic arrays, and then the language would be consistent 
about it. But instead, the compiler screams in the case that 
matters far less and allows it in the case that is clearly bad. 
So, it's inconsistent in a dumb way. At least if it were 
inconsistent by allowing it for pointers and references while 
disallowing it for arrays, it would be prventing it in the case 
that truly matters, but instead, what we have is just dumb.


- Jonathan M Davis


Let D be a dynamic array, O a pointer or object:
  | Conceptually |  in D
D == null Invalid   Valid
D is null Valid Valid
O == null Valid Invalid
O is null Valid Valid

Right?

So what you are saying is you want to create 2 more invalids in 
the table to satisfy some weird logic which requires the 
programmer to remember special cases rather than make them all 
valid and easy to remember even though it can be done and make 
sense.


In fact, the 2nd invalid makes sense and should be allowed so 
really you want to create 3 invalids for the price of one.


Simply require == null as is null and be done with it.  You can't 
police programmers minds and get them to program correctly. If 
you had a kid, do you box them up in a bubble room and not let 
them play because they might hurt themselves? How people learn is 
by making mistakes. It is better to provide a logical foundation 
that is consistent rather than produce corner cases to handle 
some corner case that was created to handle another corner case 
because someone handled a corner case.

Can I infer the type from this?

[Dr.No via Digitalmars-d-learn]

I'd like to pass a symbol as paramater (class static member0 and 
at same time get the type of this, something like this:


template myTemp(alias s)
{
enum myTemp = templateFunction!(??)(s.stringof);
}

the templateFunction has this signature:

int templateFunction(T)(string targetMembername)

but I don't how to get the type name from the give symbol name in 
myTemp. Can I make this work?

Re: How is == operator implemented for string type?

[Dr.No via Digitalmars-d-learn]

On Wednesday, 16 May 2018 at 18:56:26 UTC, Steven Schveighoffer 
wrote:

On 5/16/18 2:45 PM, Dr.No wrote:

where is the actual source code implementation?


https://github.com/dlang/druntime/blob/7e3b4086fee8f2e2a6882942c677acc28df527ee/src/object.d#L3479

-Steve


thanks

[Issue 18881] extern(C++) classes don't work properly in debuginfo

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

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

--- Comment #1 from Manu  ---
Sadly, more of my D code is extern(C++) than not >_<

--

[Issue 18881] extern(C++) classes don't work properly in debuginfo

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

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

Manu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|r.sagita...@gmx.de

--

[Issue 18881] New: extern(C++) classes don't work properly in debuginfo

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

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

  Issue ID: 18881
   Summary: extern(C++) classes don't work properly in debuginfo
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

Here's a test class:


extern(C++) class BaseCPP
{
~this() {}
void poo() {}

int x = 10;
int y = 20;
}

extern(C++) class DerivedCPP : BaseCPP
{
int z;
}

void main()
{
  DerivedCPP d = new DerivedCPP;
  BaseCPP b = d;

  int x = 10; // PLACE BREAKPOINT HERE
}


At the breakpoint, inspect the value of 'b'.

You should expect to see:
- b0x0073fb2c {z=0}   BaseCPP* {DerivedCPP}
+[DerivedCPP]  {z=0}  DerivedCPP
+__vfptr   0x00394c50 {DerivedCPP.__vftable}  void**
 x 10 int
 y 20 int


But instead, there is only the 2 members of BaseCPP: `x` and `y`.

extern(C++) classes are missing their type, entry to get from base-class
pointer to the most-derived type, and the vtable.
C++ populates the class with all this information, so extern(C++) classes
should be able to show the exact same set of members as when debugging in C++?

--

[Issue 18846] VisualD - show vtable in debugger

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

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

--- Comment #3 from Manu  ---
I just installed that build.
I can see an item in place of the vtable:

-tclass  0x02D2 Source.Base
+[Source.Derived]0x02D2 Source.Derived
 object.Object   D0006: Error: Type resolve failed  
 x   10  int
 y   20  int


It seems there's an object.Object item there, which fails to evaluate
correctly.
It should be void** (or rather, void*[N] to inspect properly) right?

--

Re: auto: useful, annoying or bad practice?

[I love Ice Cream via Digitalmars-d]

'auto' in the sense that C# and other languages use 'var' makes 
perfect sense. There is nothing wrong with it and it takes out 
redundant 'noise':


var i = "This is a string"; // don't need to know two times 
that this is a string.
var j = SomethingThatReturns(); // IDE or function docs will 
have my back here...


FYI, I wouldn't use this for 'time saving'. It's to take out 
redundant noise, which can clutter code. It also enables easy 
switching of return types from methods which occasionally means 
you don't have to change any code. It is frequent the type you 
change it to might follow the same protocol/interface as the 
previous type. Or you are just not using anything special with 
the type (maybe just forwarding a return). I do a ton of C# code 
and it's common with the .NET framework that this happens (for 
instance when working with collections). In short 'auto' or 'var' 
is not for time saving. It's to increase code readability and 
code refactorability. Those are it's benefits worth a damn.


Most people spend more time reading code than writing code so if 
you are worried about the time it takes to type out 'auto' vs. 
'SomeObnoxiouslyLongAndOverlyVerboseTypeName' then I think you 
are turning an anthill into a mountain. It's one thing when a 
language feature takes away the need to write hundreds of lines 
of common boiler plate code, but when it just prevents you from 
typing out a really long name? Come on...please...that's not why 
'auto'/'var' has gained industry recognition. There's just a lot 
of people that use it because it's an idiom without taking the 
time to understanding why it _is_ an idiom. So they say things 
like 'I type less, so I like it'.


Which brings me to where it probably is not a good place for 
it...in the return fadeclaration of a function/method. I'm very 
close to saying, even after having read some of the comments that 
try justifying it, that 100% of the time you want to specify the 
return type. When you create a function that returns something, 
you are actively deciding 'I need to return this thing, this is 
useful or the point of this function'. To not have that thing 
obviously spelled out in the API is a huge design mistake. Not 
only do you take away a self-documenting part of you function 
definition, you make someone have to either have a good IDE 
(which some people are adverse to using) or actually go read the 
source code. To not put the effort into thinking about the type 
(or constraints on the type when dealing with generic/templated 
code) is just lazy. And worse, it will facilitate libraries where 
people didn't think about their API as much as they should.

Re: is ==

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, May 19, 2018 17:13:36 Neia Neutuladh via Digitalmars-d-learn 
wrote:
> I don't think I've ever wanted to distinguish a zero-length slice
> of an array from a null array.

It's safer if you don't, because it's so easy to end up with a dynamic array
that is empty instead of null, and stuff like == doesn't care about the
difference. But there is code that's written that cares (e.g. IIRC,
std.experimental.allocator does in some cases).

if(arr)

is equivalent to

if(cast(bool)arr)

and casting a dynamic array to bool is equivalent to

arr !is null

which means that

if(arr)

means

if(arr !is null)

whereas it's not uncommon for folks to think that it means

if(arr.length != 0)

Similarly,

assert(arr);

is ultimately equivalent to

asser(arr !is null);

which suprises many folks and is rarely what folks want. So, there was a
push at one point to make it illegal to use a dynamic array in an if
statment or assertion directly, and it did briefly make it into the
compiler. However, a few folks (Andrei and Vladimir in particular IIRC), had
used arrays in if statments directly quite a bit, knowing full well what it
meant. So, their code was right (albeit potentially confusing), and they
pushed back. So, the change was reverted, and we're still stuck with the
error-prone situation that we've had.

So, most of us would argue that it's risky to treat null dynamic arrays as
special and that it should be done with caution, but programmers who know
what they're definitely do it. Unfortunately, when you read code that's
writen that way, it's usually hard to tell whether it was written with that
undertanding or not, and a stray == in the code could easily break it.

> As I already said, I use "array.length == 0". "array.empty" is
> part of that newfangled range business.

LOL. Well, if you stay away from ranges, you're losing out on a lot of
benefits - including large portions of the standard library, but checking
for length works fine if you're dealing with code that's just using dynamic
arrays and not ranges. The key thing is to avoid arr == null, because that's
were the bugs lie.

- Jonathan M Davis

Re: is ==

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, May 19, 2018 17:50:50 IntegratedDimensions via Digitalmars-d-
learn wrote:
> So, ultimately what I feels like is that you are actually arguing
> for == null to be interpreted as is null but you don't realize it
> yet.

Not really, no. Having

foo == null

be rewritten to

foo is null

in the non-dynamic array cases should be fine except for the fact that it's
then a terrible habit to be in when you then have to deal with dynamic
arrays. Using

foo == null

with dyanmic arrays is an enormous code smell, because the odds are extemely
high that the programmer thinks that they're checking if the dynamic array
is null when that's not what they're doing at all. IMHO, it should
definitely be an error to use == with null and dynamic arrays because it is
such a big code smell. Either the code should be using is to check whether
the array is null, or it should be checking length. It should never be using
== with null.

But unfortunately, the compiler is completely backwards about this and
treats it as an error with pointers and references but allows it with
dynamic arrays. If the compiler were improved to just replace == with is in
the cases that it currently treats as illegal, then that would be fine if it
then treated it as illegal with dynamic arrays. But as it stands, it is
still more efficient to use is with call references, so encouraging the
programmer to use is is benefical, and it encourages the programmer to get
in the habit of not using == with null, since it's a terrible habit to be in
with dynamic arrays. But actually making it illegal for dynamic arrays would
be a much better approach.

If it were up to me, it would just be illgal to use == with null in general,
because that's really the way it should be with dynamic arrays, and then the
language would be consistent about it. But instead, the compiler screams in
the case that matters far less and allows it in the case that is clearly
bad. So, it's inconsistent in a dumb way. At least if it were inconsistent
by allowing it for pointers and references while disallowing it for arrays,
it would be prventing it in the case that truly matters, but instead, what
we have is just dumb.

- Jonathan M Davis

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[Jonathan M Davis via Digitalmars-d]

On Saturday, May 19, 2018 22:54:16 Yuxuan Shui via Digitalmars-d wrote:
> On Thursday, 17 May 2018 at 20:32:23 UTC, Steven Schveighoffer
>
> wrote:
> > On 5/17/18 4:25 PM, DarkHole wrote:
> >> On Thursday, 17 May 2018 at 20:02:19 UTC, Steven Schveighoffer
> >>
> >> wrote:
> >>> On 5/17/18 3:55 PM, DarkHole wrote:
>  This strange code - https://run.dlang.io/is/BKgv49 - fails
>  with error "Error: constructor calls not allowed in loops or
>  after labels", but there is no loops or labels.
> >>>
> >>> Switch cases are labels.
> >>
> >> But why?
> >
> > You mean why is it an error? Probably because the compiler
> > needs to guarantee you are calling the super constructor, and
> > it can't figure out the flow when it sees labels/loops. Not
> > that it's always impossible, but it's likely a complication the
> > compiler devs don't want to deal with.
> >
> > -Steve
>
> Why isn't the compiler doing proper flow analysis? Is it that
> just no one bothered to implement it?

As I understand it, in general, Walter is against doing much in the way of
flow analysis, because it tends to become very difficult to get right in all
cases and results in situations where the programmer is forced to do
something in order to make the compiler shut up - e.g. in Java, you're
forced to initialize all variables, and it's not uncommon that you have to
initialize variables when you can clearly see that it shouldn't be
necessary, but the compiler isn't smart enough to see that. Also, if D
started use more flow analysis, then the exact rules of the flow analysis
would have to be in the spec and set in stone, or you end up with code
compiling on one compiler but not another. So, given issues like these
Walter has taken the approach of trying to avoid doing much where flow
analysis would be required by the spec.

In the case of initialization, D's approach is to default-initialize
evertything and then let the optimizer optimize out unnessary
initializations where it can, which avoids the problem that Java has and
eliminated the need to embed the flow analysis rules in the spec. And in
general, the places that D does much in the way of flow analysis is in the
optimization step where the compiler is free to change an improve how it
does flow analysis. There are a few places wheree it's forced to do basic
flow analysis (e.g. in constructors in cases like you ran into here), but in
such cases, it pretty much always sticks to simple rules so that the flow
analysis does not have to be complicated.

- Jonathan M Davis

C style callbacks fix for member callbacks

[IntegratedDimensions via Digitalmars-d-learn]

I have a member callback that I want to use as a C callback.

This is impossible due to the `hidden this` passed as the "first" 
parameter.


The callback already makes it's last value a user pointer which I 
use as a "this".


If I make my method static extern(C) then there is no crash and 
everything works. The problem is that it is now a static function 
within the class which I want to avoid.


Because there is actually a "this pointer" I can make it a member 
function and everything works as long as the calling convention 
is right.


I was initially wrapping the callback in a delegate that made it 
all work out but I want to avoid that level of indirection since 
it should not be necessary.


I have tried manually reversing the arguments, using various 
calling conventions, etc but everything crashes except when I use 
extern(C) static without modifying the order.


extern(C) static foo(a,b,c,d)

puts the parameters on the stack as d,c,b,a

foo(a,b,c,d)

is d,c,b,a,this (? The ABI does not make it clear what order is 
pushed on the stack. It uses the terminology "passes" and I 
assume that the calling convention is C'ish although extern(C) 
matters).



works

extern(C) static foo(a,b,c,d)

does not work

static foo(d,c,b,a)

So something else is going on

"The last parameter is passed in EAX rather than being pushed on 
the stack if the following conditions are met:


It fits in EAX.
It is not a 3 byte struct.
It is not a floating point type.
"

Can someone clarify the exact calling convention process for C vs 
D along with any potential solutions to the above problem(using 
static is not a solution).


Just to make sure we are on the same page:

class
{
   void extern(C) static foo(a,b,c,mythis);
}

works while

class
{
   void extern(C) foo(a,b,c);
}

fails.

class
{
   void foo(c,b,a);
}

also fails.

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[Yuxuan Shui via Digitalmars-d]

On Thursday, 17 May 2018 at 20:32:23 UTC, Steven Schveighoffer 
wrote:

On 5/17/18 4:25 PM, DarkHole wrote:
On Thursday, 17 May 2018 at 20:02:19 UTC, Steven Schveighoffer 
wrote:

On 5/17/18 3:55 PM, DarkHole wrote:
This strange code - https://run.dlang.io/is/BKgv49 - fails 
with error "Error: constructor calls not allowed in loops or 
after labels", but there is no loops or labels.


Switch cases are labels.


But why?


You mean why is it an error? Probably because the compiler 
needs to guarantee you are calling the super constructor, and 
it can't figure out the flow when it sees labels/loops. Not 
that it's always impossible, but it's likely a complication the 
compiler devs don't want to deal with.


-Steve


Why isn't the compiler doing proper flow analysis? Is it that 
just no one bothered to implement it?

[Issue 18868] Separate compilation generates two static this functions, runs it twice

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

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

--- Comment #2 from johanenge...@weka.io ---
Extra testcase that must be added and considered (currently works):
```
static foreach(s; ["666", "777"]) {
mixin(genCtor(s));
}

int i;

string genCtor(string a)
{
return "static this() { i += " ~ a ~ "; }";
}

void main()
{
assert(i == 0 + 666 + 777);
}
```

--

[Issue 18880] [REG2.079] Miscompilation of unittests when two are mixed-in on one line

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

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

--- Comment #2 from johanenge...@weka.io ---
Things are worse:

```
static foreach(s; ["666", "777"]) {
mixin(genTest(s));
}

int i;

string genTest(string a)
{
return "unittest { i += " ~ a ~ "; }";
}

void main()
{
assert(i == 0 + 666 + 666);
}
```

Thus: the exact source location is not necessarily unique and so an extra
uniqueness factor is needed to generate the unittest function names. (note:
must still be deterministic across separate compilations!)

--

[Issue 18846] VisualD - show vtable in debugger

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

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

--- Comment #2 from Manu  ---
Right, I've noticed that our pointers don't seem to show symbol names like C++
does... why is that? Is that possible to fix?
The experience should match C++.

--

[Issue 18879] !is doesn't highlight correctly

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

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

--- Comment #2 from Manu  ---
I think they should both be highlighted when used both as operators and as
keywords... so I don't think that distinction of case matters?

--

[Issue 18880] [REG2.079] Miscompilation of unittests when two are mixed-in on one line

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

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

--- Comment #1 from johanenge...@weka.io ---
Related issue discussing the mixin linecount problem:
https://issues.dlang.org/show_bug.cgi?id=2887

--

[Issue 18880] New: [REG2.079] Miscompilation of unittests when two are mixed-in on one line

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

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

  Issue ID: 18880
   Summary: [REG2.079] Miscompilation of unittests when two are
mixed-in on one line
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johanenge...@weka.io

With the change to deterministic unittest function naming, this bug was
introduced:
When N unittests are mixed-in on the same line, the first one is run N times.

Testcase:
```
mixin(genTest("666")); mixin(genTest("777"));

int i;

string genTest(string a)
{
return "unittest { i += " ~ a ~ "; }";
}

void main()
{
// All unittests have been when we reach here.
assert(i == 0 + 666 + 777);

// Since 2.079 this passes!
// assert(i == 0 + 666 + 666);
}
```
fails with:
dmd -unittest -run testcase.d
since 2.079.

It's caused by the naming of the unittest functions. The source location of the
unittest is used in the name, but the source location inside mixins behaves
strange: inside the mixin the linenumbers are offset with the line number of
the mixin statement, but the column of the mixin statement is not reflected in
Locs inside a mixin (only in the filename of the Loc).
Thus only one function is made "...__unittest_L1_C1FZv" and it is called twice.
(the second unittest gets the same name and is subsequently not codegenned
because the symbol is already defined)

--

[Issue 18880] [REG2.079] Miscompilation of unittests when two are mixed-in on one line

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

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

johanenge...@weka.io changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All
   Severity|enhancement |regression

--

Re: Sealed classes - would you want them in D? (v2)

[0xEAB via Digitalmars-d]

On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
If class level protection is added, please do not call it 
sealed.
People from c++ might be suprised by 'private' already. We do 
not have to confuse those c#ies too.


I thought the same.


Module level protection is enough to hide implementation 
details though. So while i do understand why you want this in 
D, i don't think it is worth it to complicate the language for 
something you can work around easily by putting the classes in 
their own modules.


I wouldn't consider putting classes into own modules a 
workaround. In my opinion it's more or less the solution.

[Issue 18846] VisualD - show vtable in debugger

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

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
I've implemented this, but allow disabling it with an option on the
Debugger->Mago page. You can try it in
https://ci.appveyor.com/project/rainers/visuald/build/job/sd42f639wlwh77qc/artifacts

It doesn't show symbol names, though, just raw pointer values. I'm not sure
that's good enough.

--

[Issue 18879] !is doesn't highlight correctly

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

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

--- Comment #1 from Rainer Schuetze  ---
`in` and `is` can be both operators or keywords depending on context, so
different colors are expected. A preceding `!` is a separate token, i.e. there
can be arbitrary spaces and comments in between.

This makes it pretty difficult for the lexer to highlight these correctly, but
there is actually support for that by asking the parser. It seems this is
broken, though.

--

Re: Override member variables

[Ali Çehreli via Digitalmars-d]

On 05/19/2018 11:09 AM, Gheorghe Gabriel wrote:
> I've worked with a lot of programming languages and I've found something
> interesting in Kotlin. You can override member variables. Would you like
> to have this feature in D?

It's needed in C++ and I'm sure any object-oriented programming language 
as well. As you seem do indicate, the current solution is to provide 
member functions. Assuming that the values are constant:


class Rectangle {
int width() const {
return 0;
}
int height() const {
return 0;
}
}

class Table : Rectangle {
override int width() const {
return 10;
}
override int height() const {
return 14;
}
}

void main() {
auto r = new Table();
assert(r.width == 10);
assert(r.height == 14);
}

The compiler can optimize virtual function calls away when it can prove 
the actual type.


Here is quick exercise with current language features:

mixin template overridable(string name, T...) {
static assert(T.length == 1, "You must provide a single value for 
member '" ~ name ~"'");


import std.string : format;
mixin (format(q{
%s %s() const { return %s; }
}, typeof(T[0]).stringof, name, T[0]));
}

mixin template overrided(string name, T...) {
static assert(T.length == 1, "You must provide a single value for 
member '" ~ name ~"'");


import std.string : format;
mixin (format(q{
override %s %s() const { return %s; }
}, typeof(T[0]).stringof
, name, T[0]));
}

class Rectangle {
mixin overridable!("width", 0);
mixin overridable!("height", 0);
}

class Table : Rectangle {
mixin overrided!("width", 10);
mixin overrided!("height", 14);
}

void main() {
auto r = new Table();
assert(r.width == 10);
assert(r.height == 14);
}

Ali

[Issue 18879] !is doesn't highlight correctly

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

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

Manu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|r.sagita...@gmx.de

--

Re: Real Int24

[IntegratedDimensions via Digitalmars-d-learn]

On Saturday, 19 May 2018 at 18:19:35 UTC, IntegratedDimensions 
wrote:
Is there any way to create an int24 type that behaves just like 
any other built in type without having to reimplement 
everything?


In fact, what I'd like to do is create an arbitrary type:

struct atype(T)
{

}

where atype(T) is just a "view" in to N_T bits interpreted as T, 
an enum.


If T is bit, then the N = 1 and the interpretation is 1 bit.
If T is byte, then the N = 8 and the interpretation is 7 bits 
followed by 1 signed bit.
If T is int24, then the N = 24 and the interpretation is 23 bits 
followed by 1 signed bit.


The idea is the storage of atype is exactly N bits. If this is 
not possible due to boundary issues then N can always be a 
multiple of 8(which is for my use cause is the smallest).


The main thing is that I would like to be able to use atype as if 
it were a built in type.


If N = 24, 3 bytes, I want to be able to create arrays of 
atype!int24[] which work just as if they were arrays of bytes 
without any exception or special cases.


atype!byte would be equivalent to byte and reduce to the compiler 
internals. I'm not looking to create a "view" of an array. I want 
a standalone type that can behave as all the desired types 
needed, which is most of the numerical types of D and some of the 
ones it neglected like 24-bit ints, 48-bit ints, etc. Ideally, 
any type could be used and the "most optimal" code is generated 
while being able to use the types using the standard model.

[Issue 18879] New: !is doesn't highlight correctly

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

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

  Issue ID: 18879
   Summary: !is doesn't highlight correctly
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

`in` and `is()` are highlighted as keywords, but `!in` and `!is()` are not
highlighted correctly.

--

[Issue 18878] New: Short-circuiting && not behaving correctly

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

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

  Issue ID: 18878
   Summary: Short-circuiting && not behaving correctly
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

Well, this is not okay!

enum isInternal(string field) = field.length >= 2 && field[0..2] == "__";
pragma(msg, isInternal!"x");

> error : string slice `[0 .. 2]` is out of bounds

My code used to compile.

--

Real Int24

[IntegratedDimensions via Digitalmars-d-learn]

Is there any way to create an int24 type that behaves just like 
any other built in type without having to reimplement everything?

Override member variables

[Gheorghe Gabriel via Digitalmars-d]

I've worked with a lot of programming languages and I've found 
something interesting in Kotlin. You can override member 
variables. Would you like to have this feature in D?


class Rectangle {
int width = 0;
int height = 0;
}

class Table : Rectangle {
override int width = 10;
override int height = 14;
}

In my opinion it's a more cleaner sintax and you don't need to 
put them in constructors. When you look at the Table class 
definition/documentation you see that it changes width and height 
and their new default values. I am curious about your opinions. :)

And of course, you cannot override private members.

Re: is ==

[IntegratedDimensions via Digitalmars-d-learn]

On Saturday, 19 May 2018 at 01:31:38 UTC, Jonathan M Davis wrote:
On Friday, May 18, 2018 23:53:12 IntegratedDimensions via 
Digitalmars-d- learn wrote:
Why does D complain when using == to compare with null? Is 
there really any technical reason? if one just defines == null 
to is null then there should be no problem. It seems like a 
pedantic move by who ever implemented it and I'm hoping there 
is actually a good technical reason for it.


Because == is pretty much never what you want to do with null. 
How much it matters depends on the types involved, but if you 
really want to check for null, is is definitely the right thing 
to use.


In the case of pointers and references, is checks that they're 
pointing to the same thing. So,


foo is null

directly checks whether the reference or pointer is null. On 
the other hand, if you use ==, it's calling some form of 
opEquals. For pointers, that should generate identical code, 
but for class references, it means calling the free function 
opEquals. That function will check whether the references are 
null before calling opEquals on either of the class objects, 
but it does add unnecessary overhead (which, as I understand 
it, the compiler is unfortunately not currently able to 
optimize away) and provides no benefit over checking with is.


Now, where is vs == _really_ matters (but unfortunately, the 
compiler does not complain about) is with dynamic arrays. If 
you do


arr is null

then the compiler will check whether the array's ptr is null. 
So, something like


"" is null

would be false. However, if you use ==, then it compares the 
length of the array and then only compares the ptrs if the 
length is non-zero. So,


"" == null

is true. So, with dynamic arrays, using == with null is a huge 
code smell. It _may_ be exactly what the programmer intends, 
but the odds are pretty high that they just don't properly 
understand the difference between is and ==, and they meant to 
be checking whether the array was actually null but just ended 
up checking whether its length was zero (which won't matter for 
some code but will cause subtle bugs in any code that treats 
null as special - e.g. if that is used to indicate that the 
array had not been given a value). Now, because of how == 
treats null like empty, it _is_ a bit risky to try and treat 
null as special with arrays, but anyone wanting to be clear in 
their code should either be checking null with is (in which 
case, they clearly care about null and not empty), or if they 
care about length == 0, they should either be calling empty on 
the array or explicitly checking the array's length, since 
that's what they care about. Much as having == work with null 
arrays avoids issues with segfaults due to an array be 
unitialized as well as avoids needing to give memory to an 
array just to have it be empty, you pretty much never actually 
care whether an array == null. You either care that its ptr is 
null (in which case, is checks that), or you care about whether 
its length is 0 (in which case empty or directly checking 
length checks that). arr == null is just unclear and likely 
buggy.


So really, there are _zero_ advantages to comparing null with 
==. Using == with null risks adding extra overhead, and it 
often makes the code less clear. On the other hand, using is 
makes it crystal clear what you mean and then does exactly what 
you mean - check whether the variable is actually null. So, 
maybe the compiler is being a bit pedantic by insisting that 
you use is rather than ==, but you really should be using is 
and not == when checking for null.


- Jonathan M Davis


I don't see your point.

You claim that one should never use == null for whatever reason 
and that it is "wrong". So, why are you allowing wrong things in 
a language that can easily be fixed?


Just reinterpret == null as is null and be done with it! This 
fixes the wrong and everyone can live happily ever after.


Your logic is the same how people "ban" certain words like 
faggot. They don't like them for some reason, decide that no one 
should use it any more, and create a new word that essentially 
means the same thing... and it results in a loop where that new 
word then eventually gets "banned".


== vs is might not be quite as extreme, maybe is will be the 
final "word". But if == null is banned by the compiler why the 
hell not just reinterpret to mean is null internally and be done 
with it and allow the syntax since it is so common?


The only pitfalls is pasting code from other languages that might 
have a different interpretation, but those problems always exist 
since the languages are different.


Your reasons for arrays is not good enough. First, not all types 
are arrays so you are banning a whole class of valid types for 
one case. That case, you say, is almost never meant anyways(that 
is, using == null is really meant as is null).


So, ultimately what I feels like is that you are actually arguing 
for == null to 

Re: C API / const char *text / std.string.toStringz pointer is always NULL on C side

[kinke via Digitalmars-d-learn]

On Saturday, 19 May 2018 at 17:33:08 UTC, Robert M. Münch wrote:

On 2018-05-18 14:42:17 +, Adam D. Ruppe said:
A value struct return is actually done via a hidden pointer 
parameter (so the function can construct it in-place for the 
caller, a standard optimization), so it just shifted all the 
other arguments to the side, causing one of those 0's to be 
interpreted as the string.


[...]

Is this somehwere documented?


https://docs.microsoft.com/en-us/cpp/build/return-values-cpp:


Otherwise, the caller assumes the responsibility of allocating
memory and passing a pointer for the return value as the first
argument. Subsequent arguments are then shifted one argument
to the right.

[Issue 18796] std.algorithm.substitute asserts on empty range

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

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

Andrei Vasile  changed:

   What|Removed |Added

 CC||andrei.vasil...@gmail.com
   Assignee|nob...@puremagic.com|andrei.vasil...@gmail.com

--

Re: Sealed classes - would you want them in D? (v2)

[Gheorghe Gabriel via Digitalmars-d]

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:

On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:

On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

class A {
   private int x;
   private(this) int y;
}



I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.


Mmm.. that brings me back to the idea of sealed at the class 
level again.


class A



{
   private int x;
   private(this) int y;  // imagine if you have lots of private 
variables.
 // this could become pretty anoying - 
and kinda redundant.

}

class A
{
   private int x;
   sealed int y; // again, what if you have lots of private 
variables that

 // that you really want sealed.
}


// Now. Back to the idea of sealed.
// abosolute consistency of your private variables.
// no redundancy.
// no some 'private', some 'sealed' confusion.
// no some 'private' (but really public) some 'private(this) .. 
confusion.

//
sealed class A{
private int x;
private int y;
}

downside, is adding a new keyword, and getting agreement on 
what that new keyword should be.


So I've come full circle again, and believe my idea is worth 
further consideration.


If you have
sealed class A {
   private {
   // members
   }
}
Then you can't use the defualt 'private' if you need it for a 
specific member.


But if sealed is an access type of a member, 99% you will use 
sealed insted private in a class, so it is not redundant.


class A {
   sealed {
   // members
   }
   private int friendMember;
}

And you use private keyword only if you need to access that 
variable from a class/function/struct.. in the same module, like 
a friend.

Re: C API / const char *text / std.string.toStringz pointer is always NULL on C side

[Robert M. Münch via Digitalmars-d-learn]

On 2018-05-18 14:42:17 +, Adam D. Ruppe said:


On Friday, 18 May 2018 at 14:06:11 UTC, Robert M. Münch wrote:
So, having a wrong return-type here, resulted in the const char *text 
parameter always being NULL. Not sure I understand the relation but 
looks strange to me... at least not very obvious.


A value struct return is actually done via a hidden pointer parameter 
(so the function can construct it in-place for the caller, a standard 
optimization), so it just shifted all the other arguments to the side, 
causing one of those 0's to be interpreted as the string.


Wow, thanks for the clear explanation. Without very deep internal 
knowhow I don't think anyone is able to ever guess this.


Is this somehwere documented?

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

[Issue 18877] New: std.allocator: RCIAllocator's .alignment() method is not readable at compile-time

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

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

  Issue ID: 18877
   Summary: std.allocator: RCIAllocator's .alignment() method is
not readable at compile-time
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P5
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

Created attachment 1696
  --> https://issues.dlang.org/attachment.cgi?id=1696=edit
Draft patch for making alignment a method

Many building block allocators have a line such as:

enum uint alignment = Allocator.alignment;

or:

alias alignment = ParentAllocator.alignment;

This doesn't work when the parent allocator is an opaque class.

Possible solutions:

- Forego use of alignment as a compile-time value, instead treating it as a
runtime value everywhere. Rely on compiler optimizations to punch through the
layers as needed.

  This is probably not feasible as many allocators rely on the underlying types
having a predefined, constant alignment. Using ParentAllocator.init.alignment
allows hacking around this, though.

  Attached is a draft patch towards this approach.

- Declare alignment as an enum/alias iff ParentAllocator's alignment can be
read at compile-time. For allocators that require knowing the alignment
beforehand, this can be made as an explicit check (to produce a human-readable
error message if they are used with e.g. RCIAllocator).

--

Re: Sealed classes - would you want them in D? (v2)

[Neia Neutuladh via Digitalmars-d]

On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:

On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:


The point was encapsulation as you defined it was broken. 
private members were directly modified outside their class. In 
your words, everyone was a friend.


This is why we have coding standards ;-)

https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2017/april/accessing-private-fields-outside-of-classes-in-java.pdf


Coding standards are good enough for Java but not for D?

Re: is ==

[Neia Neutuladh via Digitalmars-d-learn]

On Saturday, 19 May 2018 at 04:30:24 UTC, Jonathan M Davis wrote:
On Saturday, May 19, 2018 03:32:53 Neia Neutuladh via 
Digitalmars-d-learn wrote:
> Of course, the most notable case where using == with null is 
> a terrible idea is dynamic arrays, and that's the case where 
> the compiler _doesn't_ complain. Using == with null and 
> arrays is always unclear about the programmer's intent and 
> almost certainly wasn't what the programmer intended. If the 
> programmer cares about null, they should use is. If they 
> care about lengnth, then that's what they should check. 
> Checking null with == is just a huge code smell.


I feel like the array == null version is more explicit about 
not allocating memory. However, I'm paranoid about whether 
that's going to check the pointer instead, so I mostly use 
array.length == 0 instead.


I'm not sure what memory allocations you're worried about. 
Neither "" nor [] allocates memory


"" is syntax for compile-time constants and shouldn't ever 
allocate.


[] is a specific case of [values...]; the general case allocates, 
but this one case does not.


null is not even a compile-time constant; it's a value baked into 
the language and is guaranteed not to allocate.


but regardless, if you're looking to check whether arr.ptr is 
null, then that's effectively what you get with


arr is null


I don't think I've ever wanted to distinguish a zero-length slice 
of an array from a null array.


Regardless, if you're checking for null, then is does the job, 
and if what you care about is whether the array is empty, then 
that's what


arr.length == 0

and

arr.empty

do.


As I already said, I use "array.length == 0". "array.empty" is 
part of that newfangled range business.

Re: Sealed classes - would you want them in D? (v2)

[Neia Neutuladh via Digitalmars-d]

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
Mmm.. that brings me back to the idea of sealed at the class 
level again.


class A
{
   private int x;
   private(this) int y;  // imagine if you have lots of private 
variables.
 // this could become pretty anoying - 
and kinda redundant.

}


All attributes in D work the same way. You can write things like:

class A
{
  @Jsonize:
  private:
  int a;
  string b;

  protected
  {
long c;
  }

  @safe:
  void privateSafeFunction() {}
  void otherPrivateSafeFunction() {}
}

Perhaps you should learn more about the language before proposing 
specific changes?

[Issue 13741] std.traits.moduleName & packageName do not work with functions that have parameters

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

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

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

   What|Removed |Added

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

--

[Issue 13741] std.traits.moduleName & packageName do not work with functions that have parameters

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

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

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

https://github.com/dlang/phobos/commit/593a4e2e39312daef00023f924a0c45af1cf082c
fix issue 13741 - std.traits.moduleName does not work with functions that have
parameters

https://github.com/dlang/phobos/commit/09816a2e8b960e2f49bcbd2da754136bdd6501b8
Merge pull request #6494 from BBasile/issue-13741

fix issue 13741 - std.traits.moduleName does not work with functions that have
parameters
merged-on-behalf-of: MetaLang 

--

[Issue 18876] New: Contradiction in Spec Concerning Properties

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

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

  Issue ID: 18876
   Summary: Contradiction in Spec Concerning Properties
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: qs.il.paperi...@gmail.com

In section "Property Functions"[1] of "Functions" page, it says on 
2., second point: "@property functions can only have zero, one or two
parameters."
and on
8.: "If a property function has no parameters, it works as a getter. If has
exactly one parameter, it works as a setter."

These cannot be understood simultaneously. 8. implies a @property must have one
or no parameters.

[1] https://dlang.org/spec/function.html#property-functions

--

[Issue 18415] Typedef ignores @disabled default constructor

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

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

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

https://github.com/dlang/phobos/commit/2cd3b5dac201c4168e242adfe94996fd67050f53
fix issue 18415 - Typedef ignores `@disabled` default constructor

https://github.com/dlang/phobos/commit/b62baca794d34e37e113ef332c95c35f76f347af
Merge pull request #6514 from BBasile/issue-18415

fix issue 18415 - Typedef ignores `@disabled` default constructor
merged-on-behalf-of: MetaLang 

--

[Issue 18875] New: String literals can't disambiguate between const(char)[] and const(char)* overload.

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

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

  Issue ID: 18875
   Summary: String literals can't disambiguate between
const(char)[] and const(char)* overload.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dmitry.o...@gmail.com

void add(const(char)* path){ }

void add(const(char)[] path){ }

void main(){
add("ABC");
}


On DMD 2.080 prints:

bug.d(6): Error: bug.add called with argument types (string) matches both:
bug.d(1): bug.add(const(char)* path)
and:
bug.d(3): bug.add(const(char)[] path)


I believe that for string literals we should probably pick D version of
const(char)[]. Some might argue the other way around since it's likely a
C-string function so it will be more efficient to present it as C-string.

Truth be told we need a sentinel terminated string type in DRuntime and cstring
would be one of them.

At the very least there has to be something in the spec about this.

--

Found on proggit: simple treap language benchmark, includes D

[Joakim via Digitalmars-d]

D does well, comes in second on Mac/Win/linux:

https://github.com/frol/completely-unscientific-benchmarks
https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/

Re: auto: useful, annoying or bad practice?

[Chris via Digitalmars-d]

On Friday, 18 May 2018 at 16:25:52 UTC, Neia Neutuladh wrote:

On Friday, 18 May 2018 at 10:09:20 UTC, Chris wrote:
In a way Java has slowly been moving in that direction anyway, 
cf. this answer [2] that reminded me of D's `auto` return type.
[2] 
https://stackoverflow.com/questions/1348199/what-is-the-difference-between-the-hashmap-and-map-objects-in-java


Except the return type that you wrote in that case tells you 
almost everything you can do with that value. If you specify 
the return type of a function as `auto`, it tells you nothing. 
The Java equivalent would be to return Object.


My point was about implementing an interface you can rely on, 
regardless of what auto returns, eg:


auto name = user.name;

user could be anything, but it still has the field / property 
'name'.

[Issue 15475] Ddoc code sample with unbalanced paren comes out as macro

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

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

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

https://github.com/dlang/dmd/commit/e0e23b7250401521c8db05c079ae2b59408afb0e
Fix Issue 15475 - Fix more cases

https://github.com/dlang/dmd/commit/843dbf3fa056a0a35b5c59c58a129ec65818b24d
Merge pull request #8238 from dgileadi/ddoc-unbalanced-parens-in-code

Fix more cases of bug 15475

--

[Issue 15475] Ddoc code sample with unbalanced paren comes out as macro

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

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

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

   What|Removed |Added

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

--

[Issue 18874] Add thatneedle.com to organizations using D

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

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

m...@thatneedle.com changed:

   What|Removed |Added

 CC||m...@thatneedle.com

--

[Issue 18874] New: Add thatneedle.com to organizations using D

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

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

  Issue ID: 18874
   Summary: Add thatneedle.com to organizations using D
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: m...@thatneedle.com

http://thatneedle.com is focused on Natural Language Processing and information
retrieval/search. Thatneedle.com uses D for data processing, and rapid
prototyping.
Please keep up the great work.

--

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

[Shachar Shemesh via Digitalmars-d]

On 18/05/18 22:57, kinke wrote:
I checked, and the reason is that D and C++ use a different ABI wrt. 
by-value passing of non-POD arguments. C++ indeed passes a reference to 
a caller-allocated rvalue, not just on Win64; that makes it trivial, as 
there are no moves across call boundaries. But your proposal may imply 
changing the D ABI accordingly.


That seems to be the case.

Assuming https://dlang.org/spec/abi.html is the ABI you refer to, there 
is very little in way of argument calling there:


https://dlang.org/spec/abi.html#function_calling_conventions

"
The extern (C) and extern (D) calling convention matches the C calling 
convention used by the supported C compiler on the host system. Except 
that the extern (D) calling convention for Windows x86 is described here.

"

So the current state is, in essence, that in C everything is PoD, and 
that's why that's also the case in D. Yes, something will need to change 
there.


Shachar

Re: Need help with the dmd package on NixOS

[Thomas Mader via Digitalmars-d]

On Friday, 4 May 2018 at 20:27:33 UTC, Thomas Mader wrote:
The dmd package on NixOS doesn't work anymore in their master 
branch.
They must have changed something in the C environment or 
something and I don't have a clue what's going on.


I found the problem.
strip in binutils 2.30 is broken. Nix is stripping libs and 
binaries on installation.
The problem will be further analyzed in 
https://sourceware.org/bugzilla/show_bug.cgi?id=23199

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:


The point was encapsulation as you defined it was broken. 
private members were directly modified outside their class. In 
your words, everyone was a friend.


This is why we have coding standards ;-)

https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2017/april/accessing-private-fields-outside-of-classes-in-java.pdf

Re: Sealed classes - would you want them in D? (v2)

[Uknown via Digitalmars-d]

On Saturday, 19 May 2018 at 09:10:32 UTC, KingJoffrey wrote:

On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:


I ported your example to Java. Surprisingly, it compiled and 
executed just fine:


All I see, is a class, with static members. How else would it 
work?


This is the equivalent of my D example, in Java:

( it won't even compile.  phew!  )



The point was encapsulation as you defined it was broken. private 
members were directly modified outside their class. In your 
words, everyone was a friend.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:


I ported your example to Java. Surprisingly, it compiled and 
executed just fine:


All I see, is a class, with static members. How else would it 
work?


This is the equivalent of my D example, in Java:

( it won't even compile.  phew!  )

--
public class test
{
public static void main(String[] args)
{
Dog dog = new Dog();
dog.noiseType = "meow";  // no way jose
System.out.println(dog.makeNoise()); // phew! cause dogs 
don't meow.

}
}

class Dog
{
private String noiseType = "woof";

public String makeNoise()
{
return this.noiseType;
}
}

Re: Sealed classes - would you want them in D? (v2)

[Uknown via Digitalmars-d]

On Saturday, 19 May 2018 at 07:57:39 UTC, KingJoffrey wrote:

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:

[...]


module test;

@safeinterface class Dog
{
private string noiseType = "woof";

public string makeNoise()
{
return this.noiseType;
}
}

void main()
{
import std.stdio;

auto dog = new Dog;
dog.noiseType = "meow"; // no way jose - requires use of 
the safe interface!

writeln(dog.makeNoise()); // phew! cause dogs can only bark.
}
---


I ported your example to Java. Surprisingly, it compiled and 
executed just fine:


--- test.java
class test
{
static class Dog
{
private String noiseType = "woof";

public String makeNoise()
{
return this.noiseType;
}
}

public static void main(String[] args)
{
Dog dog = new Dog();
		dog.noiseType = "meow"; // no way jose - requires use of the 
safe interface!

System.out.println(dog.makeNoise()); // phew! cause dogs meow.
}
}
---

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
So I've come full circle again, and believe my idea is worth 
further consideration.


how about this (use a proper annotation).

This will be less likely to confuse anyone from other languages.

e.g

---
module test;

@safeinterface class Dog
{
private string noiseType = "woof";

public string makeNoise()
{
return this.noiseType;
}
}

void main()
{
import std.stdio;

auto dog = new Dog;
dog.noiseType = "meow"; // no way jose - requires use of the 
safe interface!

writeln(dog.makeNoise()); // phew! cause dogs can only bark.
}
---