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
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
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
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
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
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
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
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