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/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
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)
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!
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
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
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
21 matches
Mail list logo
