www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Bug in D?!

reply Mr. Pib <Af343 MS.com> writes:
string Q(alias T, alias D)()
{
	pragma(msg, T);
	pragma(msg, D);
	enum x = T~" = "~D~";";
	pragma(msg, x);
}


mixin(Q!(`x`, 100)());

outputs, at compile time,

x
100
x = d;

there is no lowercase d. I did initially define Q as

string Q(alias T, D)(D d)

and one might think it is remnants left over from I cleaned the 
project so it shouldn't be happening. Seems like a bug.

(I realized that I'd probably only ever pass compile time values)

Of course, using D.stringof gives the value.

The problem is the case of D.
Aug 10 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Mr. Pib wrote:


 string Q(alias T, alias D)()
 {
 	pragma(msg, T);
 	pragma(msg, D);
 	enum x = T~" = "~D~";";
 	pragma(msg, x);
 }


 mixin(Q!(`x`, 100)());

 outputs, at compile time,

 x
 100
 x = d;

 there is no lowercase d. I did initially define Q as

 string Q(alias T, D)(D d)

 and one might think it is remnants left over from I cleaned the project 
 so it shouldn't be happening. Seems like a bug.

 (I realized that I'd probably only ever pass compile time values)

 Of course, using D.stringof gives the value.

 The problem is the case of D.


nope. the problem is the *value* of D. `char(100)` == 'd'.

	string s = "<"~100~">";

yes, this works. weither this bug or not is questionable, but this is how D 
works regerding to implicit type conversions: small ints (in the range of 
[0..char.max]) will be implicitly converted to `char` if necessary.
Aug 10 2017
parent reply Mr. Pib <Af343 MS.com> writes:
On Friday, 11 August 2017 at 04:17:32 UTC, ketmar wrote:

 Mr. Pib wrote:


 string Q(alias T, alias D)()
 {
 	pragma(msg, T);
 	pragma(msg, D);
 	enum x = T~" = "~D~";";
 	pragma(msg, x);
 }


 mixin(Q!(`x`, 100)());

 outputs, at compile time,

 x
 100
 x = d;

 there is no lowercase d. I did initially define Q as

 string Q(alias T, D)(D d)

 and one might think it is remnants left over from I cleaned 
 the project so it shouldn't be happening. Seems like a bug.

 (I realized that I'd probably only ever pass compile time 
 values)

 Of course, using D.stringof gives the value.

 The problem is the case of D.


 nope. the problem is the *value* of D. `char(100)` == 'd'.

 	string s = "<"~100~">";

 yes, this works. weither this bug or not is questionable, but 
 this is how D works regerding to implicit type conversions: 
 small ints (in the range of [0..char.max]) will be implicitly 
 converted to `char` if necessary.



Wow, that is pretty screwed up! I thought D was against implicit 
conversions that might cause problems?  I'm passing an int and I 
should be able to append an int without having to worry about the 
value of the int. Instead D chose to do something very strange, 
awkward, and error prone.
Aug 11 2017
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Mr. Pib wrote:


 Wow, that is pretty screwed up! I thought D was against implicit 
 conversions that might cause problems?  I'm passing an int and I should 
 be able to append an int without having to worry about the value of the 
 int. Instead D chose to do something very strange, awkward, and error 
 prone.


this is legacy we got from trying to be C-compatible (along with int/uint 
autoconversion, and some other things). i believe that initially it was 
done to allow something like `char c = 32;`, and now it is too late to 
change it, 'cause such change will break existing code (and we're trying to 
not break the code without a *very* strong reason, even if keeping old code 
working means keeping some old quirks).
Aug 11 2017
parent Mr. Pib <Af343 MS.com> writes:
On Friday, 11 August 2017 at 22:50:53 UTC, ketmar wrote:

 Mr. Pib wrote:


 Wow, that is pretty screwed up! I thought D was against 
 implicit conversions that might cause problems?  I'm passing 
 an int and I should be able to append an int without having to 
 worry about the value of the int. Instead D chose to do 
 something very strange, awkward, and error prone.


 this is legacy we got from trying to be C-compatible (along 
 with int/uint autoconversion, and some other things). i believe 
 that initially it was done to allow something like `char c = 
 32;`, and now it is too late to change it, 'cause such change 
 will break existing code (and we're trying to not break the 
 code without a *very* strong reason, even if keeping old code 
 working means keeping some old quirks).


The problem is that that mentality perpetuates the problem. It 
keeps things from ever getting fixed and corrected by it's very 
nature... all to supposedly save time.... but how much time does 
it waste too? It would be better to break things cleanly and let 
those that get errors fix them... cause hell, after some years 
the old code will not be used more anyways or be rewritten so 
maybe it is trying to solve a problem that doesn't actually exist?
Aug 11 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:

 int and I should be able to append an int without having to 
 worry about the value of the int.


Appending an int to a string really ought to just be a type 
mismatch error.

We might be able to convince the leadership to do that too, since 
that still fits with the C compatibility guidelines.
Aug 11 2017
next sibling parent Mr. Pib <Af343 MS.com> writes:
On Friday, 11 August 2017 at 23:34:04 UTC, Adam D. Ruppe wrote:

 On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:

 int and I should be able to append an int without having to 
 worry about the value of the int.


 Appending an int to a string really ought to just be a type 
 mismatch error.

 We might be able to convince the leadership to do that too, 
 since that still fits with the C compatibility guidelines.


I'd prefer that since at least it wouldn't silently work and 
produce potentially catastrophic errors. But then that too is 
still breaking backwards compatibility(which I think is the 
plague of the 21st century).
Aug 11 2017
prev sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Fri, Aug 11, 2017 at 11:34:04PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:

 On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:

 int and I should be able to append an int without having to worry
 about the value of the int.


 
 Appending an int to a string really ought to just be a type mismatch error.
 
 We might be able to convince the leadership to do that too, since that
 still fits with the C compatibility guidelines.


I support this.  Changing the behaviour silently is definitely a no-go,
but I'm all for breaking code with wrong or questionable behaviour.
Unfortunately, I'm not sure how likely it is to convince W & A about
this one... they have previously shown resistance to changing char to
int promotion rules, even though it has caused grief elsewhere.


T

-- 
One Word to write them all, One Access to find them, One Excel to count them
all, And thus to Windows bind them. -- Mike Champion
Aug 11 2017