Printing shortest decimal form of floating point number with Mir

[jmh530]

On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
> [snip]
>
> The way I saw it the whole argumentation for a language change 
> went like this:
> 9il: This would be helpful for my lib
> Atila: Im not convinced this is good addition to the language
>
> Thats it. No more good arguments came later. If proposal has 
> only this kind of argument then ofcourse it will be rejected. 
> Even if the idea is good.
>
> You should put yourself in the boots of Atila. If you accept a 
> change that later turns out to be bad idea you cant just take 
> it out. We all would have to be with it for 10 or more years. 
> So to avoid situation that I described a proposal needs to have 
> solid argumentation and cost/benefit ratio needs to be clear to 
> make good decision.

What happened was more that Atila said why not use template 
constraints and Ilya replied it makes things overly complicated 
and Atila responded about a workaround existing and he didn't see 
why to add.

Obviously, if Atila or Walter is not in favor of something, it's 
usually better to know that sooner rather than later. However, it 
is a bit unfortunate that this never made its way farther through 
the DIP process. There was a first round review, but I think it 
was postponed before formal assessment.

>
> And for the end I want to point out that your proposal is not 
> in the same category as ast macros. If you or some one else 
> comes up with solid arguments then the outcome might be 
> different. As for me. Im do not know ins and outs of templates 
> to make a judgment if your proposal is good or not. No one 
> showed how it would benefit the code I write.

If you aren't writing templates, then it wouldn't affect you. 
However, it was deemed beneficial enough that a form of it was 
added to C++ as part of C++ 11 (was news to me as I rarely write 
C++). The paper on it is here [1], though it doesn't really get 
into the benefits of it. I'm sure there is a lot of C++ 11 and 
later code out there that uses the C++11 version of the idea.

Nevertheless, there are some differences between the C++11 
template aliases and these. C++11 adds the using syntax in 
addition to the typedef syntax. D already has the alias syntax, 
which is like using. The difference is that D's template alias 
syntax works when defining variables. It only doesn't work the 
same with type deduction in functions. In addition, one reason 
the DIP was postponed because it really had only addressed the 
short form template alias, not the long form. However, the C++ 
version only seems to support the equivalent of the short form.

Regardless, the DIP likely could have been improved by mentioning 
its inclusion in C++ 11 (and perhaps focused a bit less on 
implementation).

I wonder if the inability to do this would inhibit the ability of 
D code to interact with C++ code bases. For instance, what if you 
have a C++ function that takes a template alias and try to call 
it in D. Would you have to write out the target of the alias to 
get it to work? This kind of thing could be important. You 
wouldn't be able to use the same template aliases in D the way 
you use them in C++.

If the DIP remained focused on C++ compatibility (if that is an 
actual issue), then it would only need to support the short form 
syntax (though that may raise questions as to why not support 
both).


[1] 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf