www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - PROPOSAL: Implicit conversions of integer literals to floating point

reply Don <nospam nospam.com> writes:
BACKGROUND:
D currently uses a very simple rule for parameter matching:
* it matches exactly; OR
* it matches using implicit conversions; OR
* it does not match.

There's an important extra feature: polysemous literals (those which can 
be interpreted in multiple ways) have a preferred interpretation.
So 'a' is char (rather than wchar or dchar); 57 is an int (rather than 
short, byte, long, or uint); and 5.0 is a double (rather than float or 
real).
This feature acts as a tie-breaker in the case of ambiguity. Notice that 
the tie-breaking occurs between closely related types.
If you implement overloading on any two of the possibilities, you would 
always overload the preferred type anyway. (eg, it doesn't make sense to 
overload 'short' and 'uint' but not 'int'). So this all works in a 
satisfactory way.

THE PROBLEM:
Unfortunately, the tie-breaking fails for integer literals used as 
floating-point parameters.
Consider:

void foo(double x) {}

void main()
{
    foo(0);
}

This compiles correctly; 0 converts to double using implicit 
conversions. Now add:
void foo(real x) {}
void foo(float x) {}
And now the existing code won't compile, because 0 is ambiguous.
Adding such overloads is a common activity. It is totally unreasonable 
for it to break existing code, since ANY of the overloads would be 
acceptable.

The language doesn't have any reasonable methods for dealing with this. 
The only one that works at all is to add a  foo(int) overload. But it 
scales very poorly -- if you have 4 floating point parameters, you need 
to add 15 overloads, each with a different combination of int 
parameters. And it's wrong -- it forces you to allow int variables
to be accepted by the function (but not uint, short, long !) when all 
you really need is for literals to be supported.

And no, templates are most definitely not a solution, for many reasons 
(they break even more code, they can't be virtual functions, etc)

This problem has already hit Phobos. We inserted a hack so that sqrt(2) 
will work. But exp(1) doesn't work.
Note that the problems really arise because we've inherited C's rather 
cavalier approach to implicit conversion.

PROPOSAL:

I don't think there's any way around it: we need another level of 
implicit conversion, even if only for the special case of integer 
literals->floating point.
 From the compiler implementation point of view, the simplest way to do 
this would be to add a level between "exact" and "implicit". You might 
call it "matches with preferred conversions", or "match with literal 
conversions".

A match which involves ONLY conversions from integer literals to double, 
should be regarded as a better match than any match which includes any 
other kind of implicit conversion.
As usual, if there is more than one "preferred conversion" match, it is 
flagged as ambiguous.

BTW, I do not think this applies to other literals, or other types. It 
only applies to polsemous types, and int literal->floating point is the 
only such case where there's no tie-breaker in the target type.

It's a very special case, but a very common and important one. It 
applies to *any* overloaded floating point function. So I think that a 
special case in the language is justified.
Dec 29 2010
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 29 Dec 2010 23:46:19 -0700, Don <nospam nospam.com> wrote:


 BACKGROUND:
 D currently uses a very simple rule for parameter matching:
 * it matches exactly; OR
 * it matches using implicit conversions; OR
 * it does not match.

 There's an important extra feature: polysemous literals (those which can  
 be interpreted in multiple ways) have a preferred interpretation.
 So 'a' is char (rather than wchar or dchar); 57 is an int (rather than  
 short, byte, long, or uint); and 5.0 is a double (rather than float or  
 real).
 This feature acts as a tie-breaker in the case of ambiguity. Notice that  
 the tie-breaking occurs between closely related types.
 If you implement overloading on any two of the possibilities, you would  
 always overload the preferred type anyway. (eg, it doesn't make sense to  
 overload 'short' and 'uint' but not 'int'). So this all works in a  
 satisfactory way.

 THE PROBLEM:
 Unfortunately, the tie-breaking fails for integer literals used as  
 floating-point parameters.
 Consider:

 void foo(double x) {}

 void main()
 {
     foo(0);
 }

 This compiles correctly; 0 converts to double using implicit  
 conversions. Now add:
 void foo(real x) {}
 void foo(float x) {}
 And now the existing code won't compile, because 0 is ambiguous.
 Adding such overloads is a common activity. It is totally unreasonable  
 for it to break existing code, since ANY of the overloads would be  
 acceptable.

 The language doesn't have any reasonable methods for dealing with this.  
 The only one that works at all is to add a  foo(int) overload. But it  
 scales very poorly -- if you have 4 floating point parameters, you need  
 to add 15 overloads, each with a different combination of int  
 parameters. And it's wrong -- it forces you to allow int variables
 to be accepted by the function (but not uint, short, long !) when all  
 you really need is for literals to be supported.

 And no, templates are most definitely not a solution, for many reasons  
 (they break even more code, they can't be virtual functions, etc)

 This problem has already hit Phobos. We inserted a hack so that sqrt(2)  
 will work. But exp(1) doesn't work.
 Note that the problems really arise because we've inherited C's rather  
 cavalier approach to implicit conversion.

 PROPOSAL:

 I don't think there's any way around it: we need another level of  
 implicit conversion, even if only for the special case of integer  
 literals->floating point.
  From the compiler implementation point of view, the simplest way to do  
 this would be to add a level between "exact" and "implicit". You might  
 call it "matches with preferred conversions", or "match with literal  
 conversions".

 A match which involves ONLY conversions from integer literals to double,  
 should be regarded as a better match than any match which includes any  
 other kind of implicit conversion.
 As usual, if there is more than one "preferred conversion" match, it is  
 flagged as ambiguous.

 BTW, I do not think this applies to other literals, or other types. It  
 only applies to polsemous types, and int literal->floating point is the  
 only such case where there's no tie-breaker in the target type.

 It's a very special case, but a very common and important one. It  
 applies to *any* overloaded floating point function. So I think that a  
 special case in the language is justified.


vote++.
Dec 29 2010
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On Thu, 30 Dec 2010 07:46:19 +0100
Don <nospam nospam.com> wrote:


 This problem has already hit Phobos. We inserted a hack so that sqrt(2)=20
 will work. But exp(1) doesn't work.
 Note that the problems really arise because we've inherited C's rather=20
 cavalier approach to implicit conversion.


I'm unsure of the problem you point to. There can be two, imo, possibly int=
errelated:
* A function (like sqrt) should accept both floats (certainly via conversio=
n).
* It is considered acceptable to write an int literal (1) where a float (1.=
0) is intended.
If the issue you point is the latter, then a simple solution is for clients=
 of float/double/real interfaces to write correct literals. But this breaks=
 with a long-standing practice (esp in C-like languages.

I have faced several _possibly_ similar issues about casts/conversions betw=
een various char types on one side and signed/unsigned integer types on the=
 other.

Example:
	void f (char c) {writeln("c");}
	void f(uint i) {writeln("i");}
	f(0x1f);	// f(DEL)
writes "c". But if the second param type is int, it writes "i". I'm aware t=
his correctly follows conversion rules, but it's still weird, annoying, and=
 difficult to get right. This is also bug-prone; and the issue may not show=
 on testing, esp if one uses explicitely typed vars as arguments (instead o=
f plain literals):
	void f (char c) {writeln("c");}
	void f(int i) {writeln("i");}
	f(0x1f);	// "i"
	char DEL =3D 0x1f;
	f(DEL);		// "c"

Also, I had to discriminate 2 constructors, one accepting a string and an u=
int, the other accepting a string and an element which happened to be a cha=
r. Needed to add a third fake param. The issue became even clearer when I g=
eneralised the type to a template in which the Element type could be anythi=
ng.


denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 30 2010
parent Don <nospam nospam.com> writes:
spir wrote:

 On Thu, 30 Dec 2010 07:46:19 +0100
 Don <nospam nospam.com> wrote:
 

 This problem has already hit Phobos. We inserted a hack so that sqrt(2) 
 will work. But exp(1) doesn't work.
 Note that the problems really arise because we've inherited C's rather 
 cavalier approach to implicit conversion.


 
 I'm unsure of the problem you point to. There can be two, imo, possibly
interrelated:
 * A function (like sqrt) should accept both floats (certainly via conversion).
 * It is considered acceptable to write an int literal (1) where a float (1.0)
is intended.
 If the issue you point is the latter, then a simple solution is for clients of
float/double/real interfaces to write correct literals. But this breaks with a
long-standing practice (esp in C-like languages.


The latter. If it is considered acceptable to write an int literal when 
meaning a floating-point literals, then a tie-breaking rule is required.
If it's not acceptable, then we shouldn't allow it at all.


 
 I have faced several _possibly_ similar issues about casts/conversions between
various char types on one side and signed/unsigned integer types on the other.
 
 Example:
 	void f (char c) {writeln("c");}
 	void f(uint i) {writeln("i");}
 	f(0x1f);	// f(DEL)
 writes "c". But if the second param type is int, it writes "i". I'm aware this
correctly follows conversion rules, 


Does it? I don't see how 0x1F converts to char without an implicit 
conversion. Looks like a bug to me.
Dec 30 2010
prev sibling next sibling parent reply =?UTF-8?Q?Tomek=20Sowi=C5=84ski?= <just ask.me> writes:
Don <nospam nospam.com> wrote:

 BACKGROUND:
 D currently uses a very simple rule for parameter matching:
 * it matches exactly; OR
 * it matches using implicit conversions; OR
 * it does not match.
 
 There's an important extra feature: polysemous literals (those which
 can be interpreted in multiple ways) have a preferred interpretation.
 So 'a' is char (rather than wchar or dchar); 57 is an int (rather than
 short, byte, long, or uint); and 5.0 is a double (rather than float or
 real).
 This feature acts as a tie-breaker in the case of ambiguity. Notice
 that the tie-breaking occurs between closely related types.
 If you implement overloading on any two of the possibilities, you
 would always overload the preferred type anyway. (eg, it doesn't make
 sense to overload 'short' and 'uint' but not 'int'). So this all works
 in a satisfactory way.
 
 THE PROBLEM:
 Unfortunately, the tie-breaking fails for integer literals used as
 floating-point parameters.
 Consider:
 
 void foo(double x) {}
 
 void main()
 {
    foo(0);
 }
 
 This compiles correctly; 0 converts to double using implicit
 conversions. Now add:
 void foo(real x) {}
 void foo(float x) {}
 And now the existing code won't compile, because 0 is ambiguous.
 Adding such overloads is a common activity. It is totally unreasonable
 for it to break existing code, since ANY of the overloads would be
 acceptable.
 
 The language doesn't have any reasonable methods for dealing with
 this. The only one that works at all is to add a  foo(int) overload.
 But it scales very poorly -- if you have 4 floating point parameters,
 you need to add 15 overloads, each with a different combination of int
 parameters. And it's wrong -- it forces you to allow int variables
 to be accepted by the function (but not uint, short, long !) when all
 you really need is for literals to be supported.
 
 And no, templates are most definitely not a solution, for many reasons
 (they break even more code, they can't be virtual functions, etc)
 
 This problem has already hit Phobos. We inserted a hack so that
 sqrt(2) will work. But exp(1) doesn't work.
 Note that the problems really arise because we've inherited C's rather
 cavalier approach to implicit conversion.
 
 PROPOSAL:
 
 I don't think there's any way around it: we need another level of
 implicit conversion, even if only for the special case of integer
 literals->floating point.
 From the compiler implementation point of view, the simplest way to do
 this would be to add a level between "exact" and "implicit". You might
 call it "matches with preferred conversions", or "match with literal
 conversions".
 
 A match which involves ONLY conversions from integer literals to
 double, should be regarded as a better match than any match which
 includes any other kind of implicit conversion.
 As usual, if there is more than one "preferred conversion" match, it
 is flagged as ambiguous.
 
 BTW, I do not think this applies to other literals, or other types. It
 only applies to polsemous types, and int literal->floating point is
 the only such case where there's no tie-breaker in the target type.
 
 It's a very special case, but a very common and important one. It
 applies to *any* overloaded floating point function. So I think that a
 special case in the language is justified.


I'd cautiously say it is a reasonable proposal not to bother application
programmers with minutiae of library evolution. My concern is that
instead, programmers would have to be familiar with minutiae of D
literals to understand overload resolution.

-- 
Tomek
Dec 30 2010
parent =?UTF-8?Q?Tomek=20Sowi=C5=84ski?= <just ask.me> writes:
Tomek Sowiński <just ask.me> wrote:


 I'd cautiously say it is a reasonable proposal not to bother
 application
 programmers with minutiae of library evolution. My concern is that
 instead, programmers would have to be familiar with minutiae of D
 literals to understand overload resolution.


Another concern is that the proposal complicates the language to
eliminate a mere nuisance, not a real threat. Currently, code affected
breaks loudly and can be mended thoughtlessly.

-- 
Tomek
Dec 30 2010
prev sibling next sibling parent reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
Don wrote:


 0 converts to double using implicit conversions.


The coder should know this while typing.
The coder should know about the possible problems while typing.

Because the coder could have typed `0.0' instead of `0', the coder probably 
wanted the compile time error you described.

Therefore the modell underlying your proposal might be wrong.

-manfred
Dec 30 2010
parent reply Don <nospam nospam.com> writes:
Manfred_Nowak wrote:

 Don wrote:
 

 0 converts to double using implicit conversions.


 
 The coder should know this while typing.
 The coder should know about the possible problems while typing.
 
 Because the coder could have typed `0.0' instead of `0', the coder probably 
 wanted the compile time error you described.


No. People expect sqrt(2) to compile, and to return 1.414....
For example, it works in C and in C++.

The only other possible solution would be to disallow conversions 
integer->floating point. I doubt that would be acceptable.
Dec 30 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:


 No. People expect sqrt(2) to compile, and to return 1.414....


Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).



 For example, it works in C and in C++.


And maybe it doesn't work in OCaML.

Bye,
bearophile
Dec 30 2010
parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Don:
 

 No. People expect sqrt(2) to compile, and to return 1.414....


 
 Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).


I've got a lot of sympathy for the first alternative (absolutely NONE 
for the second!). But unfortunately, the language allows sqrt(2) to 
compile if there is only a single sqrt function.
We have here a feature which works in some cases, but not in others.

Personally, I'd love to see implicit conversions int<->floating point 
completely removed from the language. But I think there'd be an outcry 
if that happened. The next best option would be to make the implicit 
conversions usable.



 For example, it works in C and in C++.


 
 And maybe it doesn't work in OCaML.


Yes, but OCaML isn't a C-family language, inheriting C's broken 
treatment of literals.
Dec 30 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/30/10 2:13 PM, Don wrote:

 bearophile wrote:

 Don:


 No. People expect sqrt(2) to compile, and to return 1.414....


 Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).


 I've got a lot of sympathy for the first alternative (absolutely NONE
 for the second!). But unfortunately, the language allows sqrt(2) to
 compile if there is only a single sqrt function.
 We have here a feature which works in some cases, but not in others.


I agree there's an issue here, but not only with floating point numbers:

void fun(long);
void fun(ulong);
...
fun(2); // whaa?

The same problem is at work here: 2 is an int and is equally inclined to 
go to either long or ulong.

Generally I find it a bit difficult to integrate this proposal within 
the conversions framework that we have; it adds an entire new concept 
into the mix. This makes me be more conservative. For literals, all 
things considered, I don't think requiring the .0 is a major hindrance. 
For non-literals that's more of an issue:

int x = 42;
sqrt(x); // whaa?

I'm not sure to what extent this is a problem; I defer that opinion to 
Don. If this is indeed an important issue, we should address it. If not, 
I think improving the situation for literals exclusively would provide 
only marginal benefit.


Andrei
Dec 30 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 I agree there's an issue here, but not only with floating point numbers:
 
 void fun(long);
 void fun(ulong);
 ...
 fun(2); // whaa?


That's a feature, not a bug.
Dec 30 2010
parent Max Samukha <spambox d-coding.com> writes:
On 12/31/2010 02:44 AM, Walter Bright wrote:

 Andrei Alexandrescu wrote:

 I agree there's an issue here, but not only with floating point numbers:

 void fun(long);
 void fun(ulong);
 ...
 fun(2); // whaa?


 That's a feature, not a bug.


void foo(string s);
void foo(wstring s);

foo("whoa");

This fails too and is very annoying. The bug report is here 
http://d.puremagic.com/issues/show_bug.cgi?id=4592. Is it valid?
Dec 31 2010
prev sibling parent spir <denis.spir gmail.com> writes:
On Thu, 30 Dec 2010 14:34:45 -0600
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 Then people probably need to use sqrt(2.0) or sqrt(cast(double)2). =20


 I've got a lot of sympathy for the first alternative (absolutely NONE
 for the second!). But unfortunately, the language allows sqrt(2) to
 compile if there is only a single sqrt function.
 We have here a feature which works in some cases, but not in others. =20


=20
 I agree there's an issue here, but not only with floating point numbers:
=20
 void fun(long);
 void fun(ulong);
 ...
 fun(2); // whaa?
=20
 The same problem is at work here: 2 is an int and is equally inclined to=


=20

 go to either long or ulong.
=20
 Generally I find it a bit difficult to integrate this proposal within=20
 the conversions framework that we have; it adds an entire new concept=20
 into the mix. This makes me be more conservative. For literals, all=20
 things considered, I don't think requiring the .0 is a major hindrance.=20
 For non-literals that's more of an issue:
=20
 int x =3D 42;
 sqrt(x); // whaa?
=20
 I'm not sure to what extent this is a problem; I defer that opinion to=20
 Don. If this is indeed an important issue, we should address it. If not,=


=20

 I think improving the situation for literals exclusively would provide=20
 only marginal benefit.


Here is the fool man's solution: rather strict.
Context: a func expects a parameter of a given (numeric) type (including ch=
ars!).

* If a typed thingie (read: a var) is passed, then it must have the given t=
ype, or a type that does not carry any semantic difference. By this, I mean=
 eg int for long (the diff is purely implementation detail). But uint would=
 be rejected (for me, uints are conceptually ordinals or cardinal; 'integer=
' is different concept).

* If a literal is passed, then it must have a corresponding form, according=
 to:
	*char		float/dbl	unsigned	signed
	'a' '\u0041'	65.0		65		+65
In other words, in an ambiguous context, the user is requested to provide t=
he information needed to properly distinguish among possible interpretation=
s. If sqrt is a float func, then sqrt(2) does not compile, basta! This may =
provoke loud cries ;-) But, provided the rule is widely published and we wr=
ite a sensible error message, the correction is so easy...

[By the way, I would also have a single numeric type on the implementation =
side (except possibly for arbitrary sized ints) and a quartet of plainly co=
nceptual types on the language side: namely Ordinal Cardinal Integer Real. =
Yes, my computer says Fri Dec 31.]

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 30 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Don <nospam nospam.com> wrote:


 Personally, I'd love to see implicit conversions int<->floating point  
 completely removed from the language. But I think there'd be an outcry  
 if that happened.


I'd be in favor of that. Can't see it break stuff in anything but
good ways.

-- 
Simen
Dec 30 2010
parent so <so so.do> writes:
 I'd be in favor of that. Can't see it break stuff in anything but
 good ways.


I am not sure if it is that good.
Say you want to make a generic vector class that accepts both integer and  
float values.
This might seem trivial, well it is but it gets very ugly. You are going  
to need cast on each literal!
Using C (non-generic) literal system in a generic language IMHO is very  
ugly even with the existence of implicit casting.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jan 01 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On Thu, 30 Dec 2010 21:13:05 +0100
Don <nospam nospam.com> wrote:


 Yes, but OCaML isn't a C-family language, inheriting C's broken=20
 treatment of literals.


Just for information (I really mean information, not starting a new discuss=
ion): was it proposed to let down such legacy mess form C at the time when =
D1-->D2 was designed?
I know one of D's principles is that idioms that look like C code should ha=
ve C's semantics (my words). But a major verson change...

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 30 2010
prev sibling next sibling parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Don" <nospam nospam.com> wrote:

 Because the coder could have typed `0.0' instead of `0', the coder 
 probably wanted the compile time error you described.


 No. People expect sqrt(2) to compile, and to return 1.414....
 For example, it works in C and in C++.

 The only other possible solution would be to disallow conversions 
 integer->floating point. I doubt that would be acceptable.


But people don't expect 1/2 to return 0.5000 and D isn't C++
Dec 30 2010
next sibling parent so <so so.do> writes:
 But people don't expect 1/2 to return 0.5000 and D isn't C++


People don't expect it because of the existence of a rule that makes no  
sense.
I would absolutely expect 1/2 to return 0.5!

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 30 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Alex_Dovhal:


 But people don't expect 1/2 to return 0.5000 and D isn't C++ 


There are languages that have had to wait for a major language update to reach
that:
http://ideone.com/YdFbl

While other ones have gotten it right from the beginning (Scheme numerical
tower is well designed):
http://ideone.com/q2Hot

Bye,
bearophile
Dec 30 2010
parent reply so <so so.do> writes:
 But people don't expect 1/2 to return 0.5000 and D isn't C++


 There are languages that have had to wait for a major language update to  
 reach that:
 http://ideone.com/YdFbl


I am not familiar with Python and its community, but such a change in a  
language even in a major update... great work!


 While other ones have gotten it right from the beginning (Scheme  
 numerical tower is well designed):
 http://ideone.com/q2Hot


 From the example, looks like it evaluates integer divisions to rational  
numbers while real numbers output real numbers.
This wouldn't work on a language like D.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 30 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
FYI, there is a bug with long literals and cross-module overloading.
But I've managed to screw up the first report over 4 months ago and
just noticed it now (sorry!). The revised report is in the second
comment:

http://d.puremagic.com/issues/show_bug.cgi?id=4702#c1
Dec 30 2010
parent reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
Andrej Mitrovic wrote:


 bug with [...] cross-module overloading


"Overload sets can be merged with an alias declaration"
http://www.digitalmars.com/d/2.0/function.html (cited 12/31/10)

-manfred
Dec 30 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/31/10, Manfred_Nowak <svv1999 hotmail.com> wrote:

 Andrej Mitrovic wrote:


 bug with [...] cross-module overloading


 "Overload sets can be merged with an alias declaration"
 http://www.digitalmars.com/d/2.0/function.html (cited 12/31/10)

 -manfred


That's not the point. The point is it works with a long variable, but
not with a long literal.
Dec 30 2010
parent reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
Andrej Mitrovic wrote:


 "Overload sets can be merged with an alias declaration"




[...]

 That's not the point. The point is it works with a long variable, but
 not with a long literal.


???

According to the specs it shoudn't compile in both cases.

-manfred
Dec 30 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/31/10, Manfred_Nowak <svv1999 hotmail.com> wrote:

 Andrej Mitrovic wrote:


 "Overload sets can be merged with an alias declaration"




 [...]

 That's not the point. The point is it works with a long variable, but
 not with a long literal.


 ???

 According to the specs it shoudn't compile in both cases.

 -manfred


s/spec/tdpl/

I've put it in the bugzilla, whatever the real problem is. And that
sample was taken from the Dible. (a.k.a. D Bible, a.k.a. TDPL).
Dec 30 2010
parent Max Samukha <spambox d-coding.com> writes:
On 12/31/2010 04:47 AM, Andrej Mitrovic wrote:

 On 12/31/10, Manfred_Nowak<svv1999 hotmail.com>  wrote:

 Andrej Mitrovic wrote:


 "Overload sets can be merged with an alias declaration"




 [...]

 That's not the point. The point is it works with a long variable, but
 not with a long literal.


 ???

 According to the specs it shoudn't compile in both cases.

 -manfred


 s/spec/tdpl/

 I've put it in the bugzilla, whatever the real problem is. And that
 sample was taken from the Dible. (a.k.a. D Bible, a.k.a. TDPL).


No way. Walter said D was not a religion.
Dec 31 2010
prev sibling parent "Manfred_Nowak" <svv1999 hotmail.com> writes:
Don wrote:


 disallow conversions integer->floating point


In version 0.80 floating point->integer was disallowed. The reasons that 
triggered that disallowance in 0.80 are symmetric.

A reason was:
   `(4,2)' might be mistyped as `(4.2)'
and symmetric means:
   `(4.2)' might be mistyped as `(4,2)'

Such typing errors are close to undetactability and known to have caused 
tremendous hazard. In D they can be accompanied by the usage of appropriate 
overloads or variadic templates.

Therefore disallowing implicit conversions integer->floating point is the 
right way to go.

Otherwise I will feel no sorry for those who get an output of "21.414" when 
they expected "2.049".

-manfred
Dec 30 2010
prev sibling parent reply so <so so.do> writes:
 This problem has already hit Phobos. We inserted a hack so that sqrt(2)  
 will work. But exp(1) doesn't work.
 Note that the problems really arise because we've inherited C's rather  
 cavalier approach to implicit conversion.


Classifying 2 as an int was a very wrong start.
This proposal reminds me my proposal on polysemous literals that i had a  
hard time explaining. (Still, i am not sure if anyone got the point)
Dec 30 2010
parent Don <nospam nospam.com> writes:
so wrote:

 This problem has already hit Phobos. We inserted a hack so that 
 sqrt(2) will work. But exp(1) doesn't work.
 Note that the problems really arise because we've inherited C's rather 
 cavalier approach to implicit conversion.


 
 Classifying 2 as an int was a very wrong start.


Exactly. It's not a int, it's the number two!


 This proposal reminds me my proposal on polysemous literals that i had a 
 hard time explaining. (Still, i am not sure if anyone got the point)


Yes, this is far from the first time that this issue has been noticed.
Dec 30 2010