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
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
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 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
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 "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 "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 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 next 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.

 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
prev sibling 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 next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next 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 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

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=

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

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