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
On 12/31/2010 04:47 AM, Andrej Mitrovic wrote:
On 12/31/10, Manfred_Nowak 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
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 fa
Don:
> 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.
It's a significant change. How much work does it need to create a complied side
branch of DMD 2.051 with this difference? Wi
On 12/31/10, Manfred_Nowak 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 case
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
On Thu, 30 Dec 2010 14:34:45 -0600
Andrei Alexandrescu wrote:
> >> 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
On Thu, 30 Dec 2010 21:13:05 +0100
Don wrote:
> Yes, but OCaML isn't a C-family language, inheriting C's broken
> treatment of literals.
Just for information (I really mean information, not starting a new
discussion): was it proposed to let down such legacy mess form C at the time
when D1-->D
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)
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.
Don 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
On 12/31/10, Manfred_Nowak 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 l
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
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
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!
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,
spir wrote:
On Thu, 30 Dec 2010 07:46:19 +0100
Don 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 o
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
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
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://i
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/
"Don" 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 d
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
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
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
Tomek Sowiński 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 concer
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.
Theref
Don 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) ha
On Thu, 30 Dec 2010 07:46:19 +0100
Don 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 p
On Wed, 29 Dec 2010 23:46:19 -0700, Don 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 interpr
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 interpretat
31 matches
Mail list logo
