Thread overview
Bug in D?!
Aug 11
Mr. Pib
Aug 11
ketmar
Aug 11
Mr. Pib
Aug 11
ketmar
Aug 11
Mr. Pib
Aug 11
Mr. Pib
August 11
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.




August 11
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.
August 11
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.

August 12
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).
August 11
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?
August 11
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.
August 11
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).

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