"Pavel Minayev" <evilone@omen.ru> wrote in message news:a8n8c3$1db8$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a8n4jq$19iu$1@digitaldaemon.com...
>
> > How about this:
> ...
> > Where the compiler will interpret any
> > argument that fits a category as an exact match.
> > Implementation of the function will always
> > take the largest size available on the platform
> > for that type category, making all smaller
> > sizes 'fit'.
>
> Isn't it simplier to just use "long" and "extended" (since they are always the largest, on any platform)?
>
>

But then you keep the problem that it
isn't an exact match. With type
categories the programmer could
explicitly state that he allows all
types in the category to be used and
that he expects that behaviour.

Any integer type would always be a
valid 'exact match' with any integral
argument. Only if there where a function
that was an exact match based on type
instead of type category, that function
would be called instead.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a8njrd$1qjh$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a8naiu$1fr8$1@digitaldaemon.com...
>
> > For the abs() case, I'd just do abs(long) for integral types, and
> > fabs(extended) for floating point types.
>
> So:
>     min and fmin
>     max and fmax
>     avg and favg
>     ...

Worse than that, since you can compare characters for greater than, etc. it seems reasonable to allow max and min on them as well.  Now you have three types to declare for those.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a8pt6h$2g47$1@digitaldaemon.com...

> Worse than that, since you can compare characters for greater than, etc.
it
> seems reasonable to allow max and min on them as well.  Now you have three types to declare for those.

If I recall it correctly, characters are castable to ints, so the integer version would be used by the compiler.

I kind of like this idea, but isn't it very much like templates & traits.

If Walter would be interested in incorporating a (designed from the ground up, hence) better template implementation than has C++ (resulting in all the arcane wangles we have to do to get traits to manipulate type categories, etc.), then I think the appeal of D would widen very quickly (not that it isn't appealing already ... ;)

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a8p5km$12d5$1@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a8n8c3$1db8$1@digitaldaemon.com...
> > "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a8n4jq$19iu$1@digitaldaemon.com...
> >
> > > How about this:
> > ...
> > > Where the compiler will interpret any
> > > argument that fits a category as an exact match.
> > > Implementation of the function will always
> > > take the largest size available on the platform
> > > for that type category, making all smaller
> > > sizes 'fit'.
> >
> > Isn't it simplier to just use "long" and "extended" (since they are always the largest, on any platform)?
> >
> >
>
> But then you keep the problem that it
> isn't an exact match. With type
> categories the programmer could
> explicitly state that he allows all
> types in the category to be used and
> that he expects that behaviour.
>
> Any integer type would always be a
> valid 'exact match' with any integral
> argument. Only if there where a function
> that was an exact match based on type
> instead of type category, that function
> would be called instead.
>
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>
>