Printing shortest decimal form of floating point number with Mir

ag0aep6g anonymous at example.com
Tue Jan 5 17:13:01 UTC 2021


On 05.01.21 11:44, Ola Fosheim Grøstad wrote:
> So, does that mean that you agree that having better unification would 
> be a worthwhile item to have on a wish list for 2021? So, if somebody 
> want to do a full implementation that performs well, then it would be an 
> interesting option?

Sure. I've said in my first post in this thread that "issue 1807 is well 
worth fixing/implementing".

> Quite frankly, it is much better to just say "oh, this is a deficiency 
> in the implementation" than to say that the language spec is fubar...

It's not either or. The spec on IFTI is lacking. That's true whether we 
we call issue 1807 a bug or an enhancement.

I don't think it's a productive use of our time, but if you'd like to 
argue semantics, here's why I don't consider issue 1807 a "bug":

(PS: This turned out longer than planned. Please feel free to ignore.)

A program has a bug when it doesn't behave as intended by its author. I 
think that's a pretty permissive definition of bug. So, DMD has a bug 
when it doesn't behave as Walter intended when he wrote or accepted the 
code.

I see no evidence that IFTI's type deduction was ever intended to behave 
as requested in issue 1807. The spec doesn't say it should work. Walter 
has not come forward to say that he made a mistake in the implementation.

I do see evidence that the existing deduction works as intended: Walter 
has called issue 1807 a "good idea for an enhancement request"[2], i.e. 
not a bug.

Maybe most importantly, the existing behavior just feels like the kind 
of thing Walter does. Start with trivial deduction, allowing this:

     void f(T)(T p) {}
     int x;
     f(x);

Then also allow derived types (e.g. pointers), because all the needed 
info is readily available in the type (DMD can get `int` from the type 
`int*`):

     void f(T)(T* p) {}
     int* x;
     f(x);

Then realize that types created from templates also keep the needed info 
around for name mangling (DMD can get `S` and `int` from the type 
`S!int`). Use that to allow:

     struct S(T) {}
     void f(S!T p) {}
     S!int x;
     f(x);

Done. Incremental improvements lead to a system that works pretty well a 
lot of the time. That's Walter's signature, isn't it?

> Also, the whole idea of writing the language spec to match the 
> implementation is not a good approach.

I don't disagree. But we have to work with what we got. The 
implementation exists. The spec doesn't.

Documenting the existing system has merit, even when you or someone else 
eventually finds the time and motivation to design a better one.


[1] https://dlang.org/spec/template.html#function-templates
[2] https://issues.dlang.org/show_bug.cgi?id=1807#c1


More information about the Digitalmars-d-announce mailing list