Look at the following:

typedef ubyte AAA;

class CLASS
{
 void func(AAA a, ubyte b) {}
 void func(byte a, ubyte b) {}

 void wrapper(AAA a) { func(a, 0); }
 void wrapper(byte a) { func(a, 0); }
}

It is quite clear to me, but it results in an ambiguity error.
If the func()s don't take a second argument, it is no longer ambiguous.
Maybe I'm missing something... or it is a bug in the compiler?
_________________________________

I'm going to suggest some new sintax to make overloading easier:
we have 'l' (long) and 'u' (unsigned) suffix to get long and unsigned
integers (e.g. '10ul').
Why not to have 's' (short) and 'b' (byte)?
I fear that they'll be misunderstood ('s' can mean signed and 'b' is binary,
according to assembly sintax).
They'll be useful though.

"Dario" <supdar@yahoo.com> wrote in message news:al7lnu$48m$1@digitaldaemon.com...
> Look at the following:
>
> typedef ubyte AAA;
>
> class CLASS
> {
>  void func(AAA a, ubyte b) {}
>  void func(byte a, ubyte b) {}
>
>  void wrapper(AAA a) { func(a, 0); }
>  void wrapper(byte a) { func(a, 0); }
> }
>
> It is quite clear to me, but it results in an ambiguity error.
> If the func()s don't take a second argument, it is no longer ambiguous.
> Maybe I'm missing something... or it is a bug in the compiler?

With overloading, D deliberately dispenses with the C++ idea of some type conversions being better than others. In D, there are 3 results from an overload compare: exact match, match with conversions, and no match. This is a reaction to C++'s rules being pages to express, and can get difficult to figure out when looking at multiple arguments.


> I'm going to suggest some new sintax to make overloading easier:
> we have 'l' (long) and 'u' (unsigned) suffix to get long and unsigned
> integers (e.g. '10ul').
> Why not to have 's' (short) and 'b' (byte)?
> I fear that they'll be misunderstood ('s' can mean signed and 'b' is
binary,
> according to assembly sintax).
> They'll be useful though.

The same result can be achieved with (short)s and (byte)b.

> > Look at the following:
> >
> > typedef ubyte AAA;
> >
> > class CLASS
> > {
> >  void func(AAA a, ubyte b) {}
> >  void func(byte a, ubyte b) {}
> >
> >  void wrapper(AAA a) { func(a, 0); }
> >  void wrapper(byte a) { func(a, 0); }
> > }
> >
> > It is quite clear to me, but it results in an ambiguity error.
> > If the func()s don't take a second argument, it is no longer ambiguous.
> > Maybe I'm missing something... or it is a bug in the compiler?
>
> With overloading, D deliberately dispenses with the C++ idea of some type conversions being better than others. In D, there are 3 results from an overload compare: exact match, match with conversions, and no match. This
is
> a reaction to C++'s rules being pages to express, and can get difficult to figure out when looking at multiple arguments.

I don't understand, are rules different when dealing with multiple arguments?

In the example above, see the function
void wrapper(AAA a) { func(a, 0); }

It calls func(AAA,ubyte), and the arguments match exactly. So, there is no need to look for matches with conversions. So no ambiguity. Isn't this straightforward enough? Should the language rules say it's ambiguous?

> > I'm going to suggest some new sintax to make overloading easier:
> > we have 'l' (long) and 'u' (unsigned) suffix to get long and unsigned
> > integers (e.g. '10ul').
> > Why not to have 's' (short) and 'b' (byte)?
> > I fear that they'll be misunderstood ('s' can mean signed and 'b' is
> binary,
> > according to assembly sintax).
> > They'll be useful though.
>
> The same result can be achieved with (short)s and (byte)b.

Yep, but 10b is shorter and sometimes prettier.

I hate to be forced to write 'write(cast(byte) 0x66);'
Doesn't 'write(0x66b);' look better.
Maybe it's less visible but it doesn't need to be visible: in fact, when I
write 0x66 I expect it to be 1 byte long since it has 2 digits.

Anyway, we have 'l' and 'u', but we can also write (long)l and (uint)u.
I think that casts to bytes are more frequent than casts to longs, aren't
they?

Just my humble opinions...

"Dario" <supdar@yahoo.com> wrote in message news:alb3r5$19uh$1@digitaldaemon.com...
> I don't understand, are rules different when dealing with multiple arguments?

No.

> In the example above, see the function
> void wrapper(AAA a) { func(a, 0); }
> It calls func(AAA,ubyte), and the arguments match exactly. So, there is no
> need to look for matches with conversions. So no ambiguity. Isn't this
> straightforward enough? Should the language rules say it's ambiguous?

No, they don't match exactly, as 0 is type int, not a byte.

> > The same result can be achieved with (short)s and (byte)b.
> Yep, but 10b is shorter and sometimes prettier.


> Anyway, we have 'l' and 'u', but we can also write (long)l and (uint)u.
> I think that casts to bytes are more frequent than casts to longs, aren't
> they?

I agree it's inconsistent, I never use those suffixes anyway <g>.

>
>I agree it's inconsistent, I never use those suffixes anyway <g>.
>


Walter there should always be some way to specify the type of a constant.  The 'L' suffix in certain C++ environments (to signify double-precision) is important in many applications.  Define pi otherwise and you lose 6 significant digits in every computation.

Maybe double{3.14159.....} or float(14) or some similar syntax?

M.

Dario wrote:

> I hate to be forced to write 'write(cast(byte) 0x66);'
> Doesn't 'write(0x66b);' look better.

Note that 0x66b is a valid hex number.
"s" could be used for short, but "b" is already used...

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:albmkc$5j2$1@digitaldaemon.com...
> Walter there should always be some way to specify the type of a constant.
The
> 'L' suffix in certain C++ environments (to signify double-precision) is important in many applications.  Define pi otherwise and you lose 6
significant
> digits in every computation.

You're right, I forgot about that case.

> Maybe double{3.14159.....} or float(14) or some similar syntax?

It just seems unnecessary.

>
>> Maybe double{3.14159.....} or float(14) or some similar syntax?
>
>It just seems unnecessary.
>

Here's the necessity.  In technical work one often writes code involving one-time conversion factors (that should be double precision or better).  These factors depend heavily on the units involved and the particular formula expressed.  They change often during development and sometimes disappear and reappear as the work proceeds.  Consequently they should appear directly in the expression, not as stand-alone constants in some header file.  This positioning localizes the issue of writing correct code and makes formulas easier to read.

If I have a formula

x = 123.4567890001 * y^2 + 9876.5432100001;

That is much easier to read than

x = my_special_one_time_conversion_factor_A34 * y^2 + my_special_one_time_constant_p54;

The latter is the kind of monster created when the compiler defaults every float to single precision but the formula requires double precision.  Effectively the user must work around the compiler's limitations.

So in general it's a Good Thing to have some syntax to specify the precision of numeric constants.  Lacking one, I would definitely argue that all floating point numeric constants should be double precision, not single.

Perhaps some variation on the C-language 0x and 0b prefixes would work.  I like the shorthand DBL and SGL myself.

Thanks for listening Walter!  I think it's great how you are getting feedback on the development of this new language...maybe a first in the history of computing.

Mark

Mark Evans wrote:

> So in general it's a Good Thing to have some syntax to specify the precision of
> numeric constants.  Lacking one, I would definitely argue that all floating
> point numeric constants should be double precision, not single.

AFAIK, both C++ and D treat no-suffix floating point constants
as double!

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:algcju$2l2m$1@digitaldaemon.com...
> The latter is the kind of monster created when the compiler defaults every
float
> to single precision but the formula requires double precision.
Effectively the
> user must work around the compiler's limitations.

What I do is cast one of the operands to double, that forces the whole expression to be done as a double.

> So in general it's a Good Thing to have some syntax to specify the
precision of
> numeric constants.  Lacking one, I would definitely argue that all
floating
> point numeric constants should be double precision, not single.

The trouble is, the game programmers will object. They want the speed of all float computations.

> Thanks for listening Walter!  I think it's great how you are getting
feedback on
> the development of this new language...maybe a first in the history of computing.

Actually, it's a lot of fun.