I hate to keep this subject up, but have you considered explicit overloading?

With explicit overloading, the function used will default to the default function, unless an explicit one has been defined specifically for that type.

ie

double sqrt(int val) {};
explicit float sqrt(int val) {};
explicit int sqrt(int val) {};

Therefore if a short is given, it will default to the double method, but if a float is given it will use the explicit type. The programmer can optimise the float and int methods for better performance.


Of cause there are some disadvantages of this to true overloading (having do explicit more types), but It kind meets halfway.


"Pavel Minayev" <evilone@omen.ru> wrote in message news:adcv46$31cl$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:adck5l$2mun$1@digitaldaemon.com...
>
> > Ok, seems resonable. So it's D fault for having a weak type system for returns types. And you like D having weak typing for return?
>
> Yes. I don't want to perform a cast each time I assign a value returned by a double function to int.
>
> BTW, this applies not only to the return statement, but to the entire system. It's not Java, and it's another reason why I like D.
>
> ... now if we only didn't need cast to assign a void* pointer to
> something else (like in C) ...
>
>

(Just fixed some grammar)

 I hate to keep this subject going, but have you considered explicit
 overloading?

 With explicit overloading, the function used will use the default
function, unless an explicit one has been defined specifically for that
type.

 ie

 double sqrt(int val) {};
 explicit float sqrt(int val) {};
 explicit int sqrt(int val) {};

Therefore if a short is given, it will default to the double method, but if a float is given it will use the explicit type. The programmer can optimise the float and int methods for better performance.

Of cause there are some disadvantages of this to true overloading (having do explicit for more types), but it kind'a meets halfway.

"anderson" <anderson@firestar.com.au> wrote in message news:adeqr9$8lt$1@digitaldaemon.com...

>  I hate to keep this subject going, but have you considered explicit
>  overloading?
>
>  With explicit overloading, the function used will use the default
> function, unless an explicit one has been defined specifically for that
> type.

Then, this should be applied to parameter overloading, for consistency.
But in this form, it is possible. I guess you've convinced me, now
you should do the same to Walter... =)

I kind of like this use of explicit.  Would it be better than this?

default double sqrt(double val) {}
float sqrt(float val) {}
extended sqrt(extended val) {}
int sqrt(int val) {}

Something I always wanted in C++ was the ability to mark operator typeconvert as explicit.

Has anyone tried to do something like an iterator in D yet?  I suppose you could just return slices but that has the potential to copy lots of data around.  And the data structure might not be an array.

Sean

"anderson" <anderson@firestar.com.au> wrote in message news:adelqm$37h$1@digitaldaemon.com...
> I hate to keep this subject up, but have you considered explicit overloading?
>
> With explicit overloading, the function used will default to the default function, unless an explicit one has been defined specifically for that type.
>
> ie
>
> double sqrt(int val) {};
> explicit float sqrt(int val) {};
> explicit int sqrt(int val) {};
>
> Therefore if a short is given, it will default to the double method, but
if
> a float is given it will use the explicit type. The programmer can
optimise
> the float and int methods for better performance.
>
>
> Of cause there are some disadvantages of this to true overloading (having
do
> explicit more types), but It kind meets halfway.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:adf70n$o09$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message
> news:adeqr9$8lt$1@digitaldaemon.com...
> Then, this should be applied to parameter overloading, for consistency.

I agree, that way you know instantaly that something has been overloaded and there's no ambiguity.

Also I don't think it would cause many hard ackes in porting overloads because the compiler would report an error. Then the programmer would simply had explicit to the overloads, and in the odd cases where D casting coversion is differn't, they'd simply add another explicit.

Perhaps a different term/keyword then "explicit" (I'm fine with explicit).
Any suggestions? Here are mine:
overload
explic
oload, (but I don't like, overl)

> But in this form, it is possible. I guess you've convinced me, now

Thanks, I do think overloading can be a rather powerful tool in reducting libary complexity.

> you should do the same to Walter... =)
You seem to be the best at that! ;) (Not that I'm asking you to do
anything.)

Yes, for many reasons.

Portablily, non-overloaded functions are decleared the same way and can be easily made overloaded without a change to the base function. In the case of sqrt, you may not even have access to the default function.

Also you could for example define a double sqrt function and later decide that it's not optimal for int. It's easier to then add an explicit function rather then modify the orignal.

Although I'm open to ideas I'd vote against a default like that.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adf73u$o1k$1@digitaldaemon.com...
> I kind of like this use of explicit.  Would it be better than this?
>
> default double sqrt(double val) {}
> float sqrt(float val) {}
> extended sqrt(extended val) {}
> int sqrt(int val) {}
>
> Something I always wanted in C++ was the ability to mark operator typeconvert as explicit.
>
> Has anyone tried to do something like an iterator in D yet?  I suppose you could just return slices but that has the potential to copy lots of data around.  And the data structure might not be an array.
>
> Sean
>
> "anderson" <anderson@firestar.com.au> wrote in message news:adelqm$37h$1@digitaldaemon.com...
> > I hate to keep this subject up, but have you considered explicit overloading?
> >
> > With explicit overloading, the function used will default to the default function, unless an explicit one has been defined specifically for that type.
> >
> > ie
> >
> > double sqrt(int val) {};
> > explicit float sqrt(int val) {};
> > explicit int sqrt(int val) {};
> >
> > Therefore if a short is given, it will default to the double method, but
> if
> > a float is given it will use the explicit type. The programmer can
> optimise
> > the float and int methods for better performance.
> >
> >
> > Of cause there are some disadvantages of this to true overloading
(having
> do
> > explicit more types), but It kind meets halfway.
>
>
>

Unless D supported both of coarse, because the "default" method would require less typing in some situations. And the default method could require prior planning, otherwise everthing automaticly becomes default. And having two methods may be confusing ie

default double sqrt();
explicit int sqrt();
float sqrt(); //What is this? Explicit I suppose.

So I still think explicit method is better even though It requires more typing.

"anderson" <anderson@firestar.com.au> wrote in message news:adf8op$pnp$1@digitaldaemon.com...
> Yes, for many reasons.
>
> Portablily, non-overloaded functions are decleared the same way and can be easily made overloaded without a change to the base function. In the case
of
> sqrt, you may not even have access to the default function.
>
> Also you could for example define a double sqrt function and later decide that it's not optimal for int. It's easier to then add an explicit
function
> rather then modify the orignal.
>
> Although I'm open to ideas I'd vote against a default like that.
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adf73u$o1k$1@digitaldaemon.com...
> > I kind of like this use of explicit.  Would it be better than this?
> >
> > default double sqrt(double val) {}
> > float sqrt(float val) {}
> > extended sqrt(extended val) {}
> > int sqrt(int val) {}
> >
> > Something I always wanted in C++ was the ability to mark operator typeconvert as explicit.
> >
> > Has anyone tried to do something like an iterator in D yet?  I suppose
you
> > could just return slices but that has the potential to copy lots of data around.  And the data structure might not be an array.
> >
> > Sean
> >
> > "anderson" <anderson@firestar.com.au> wrote in message news:adelqm$37h$1@digitaldaemon.com...
> > > I hate to keep this subject up, but have you considered explicit overloading?
> > >
> > > With explicit overloading, the function used will default to the
default
> > > function, unless an explicit one has been defined specifically for
that
> > > type.
> > >
> > > ie
> > >
> > > double sqrt(int val) {};
> > > explicit float sqrt(int val) {};
> > > explicit int sqrt(int val) {};
> > >
> > > Therefore if a short is given, it will default to the double method,
but
> > if
> > > a float is given it will use the explicit type. The programmer can
> > optimise
> > > the float and int methods for better performance.
> > >
> > >
> > > Of cause there are some disadvantages of this to true overloading
> (having
> > do
> > > explicit more types), but It kind meets halfway.
> >
> >
> >
>
>

Just a thought to extend the idea further.

What if it would be possible to tell the compiler, arguments of which type does this function expect. The syntax could be something like this:

    long abs(long cast(byte, short, int) n);
    extended abs(extended cast(float, double) n);

These two lines declare _two_ abs() functions, one taking a long argument,
another takes extended. However, for types byte, short and int, first
version is called (and argument is cast to long), and for float and
double, the second version is called. This is essentially the same as
if there was a set of overloaded functions:

    long abs(long n);
    long abs(int n) { return abs(cast(long) n); }
    long abs(short n) { return abs(cast(long) n); }
    long abs(byte n) { return abs(cast(long) n); }

Only shorter, and the compiler might decide not to use inline wrappers,
but to resolve ambiguity just by looking at the list of possible
types for each argument.

What do you think?

P.S. The same could be applied to return type as well...

I was thinking along the same lines, but I couldn't get it into words and you brought it up. I think it's an excellent idea.

The only problem I can see with this is that we don't want to make the programmer go to have to type to much to overload.

What about these problems to solve,

Declared in module 1
long abs(long cast(byte, short, int) n);

Declared in module 2
extended abs(extended cast(int ,float, double) n);

So I suppose in this situtation a complier error message would be triggered, if two overloads shared the same type. But a better Idea would be to use module 2 for the int in it's local space.

It'd also be good to have an alternative method to save on typing

extended abs(extended allbut(int) n); //Would do everything except int
values

Extending some of my orignal ideas.
If a function is deleared without a in built cast it becomes default. You
can overwrite (not overload) a default function for local use (like you can
already). You cannot however overwrite a default function twice in the same
local space.

If a function contains the cast word then it is explictly saying to overload those values. You can overwrite (not overload) a cast function for local use. You cannot however overwrite a cast for the same types function twice in the same local space.

ie 1 -Wrong
Module 1
long abs(long n); (default function) //OK works in local space
long abs(int n); (default function) //ERROR, cannot overwrite must cast

ie 2 -Correct
Module 1
long abs(long n); //(default function) //OK works in local space

Module 2
long abs(int n); //(default function) //OK works in local space

ie 3
Module 1
long abs(long n); //(default function) //OK works in local space

Module 2
long abs(int n); //(default function)
long abs(int cast(int, long) n); //(cast function)
long abs(int cast(int, double) n); //ERROR, ambiguus choice available

ie 3
Module 1
long abs(long n); //(default function) //OK works in local space
long abs(int cast(int, double) n); //OK works in local space

Module 2
long abs(int n); //(default function)
long abs(int cast(int, long) n); //(cast function)

You get the idea though.
That's my solution to that problem, you may have already though of that far
ahead of me.

So of course using your method (which I happen to like), does make things
more tricky.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:adfleq$175n$1@digitaldaemon.com...
> Just a thought to extend the idea further.
>
> What if it would be possible to tell the compiler, arguments of which type does this function expect. The syntax could be something like this:
>
>     long abs(long cast(byte, short, int) n);
>     extended abs(extended cast(float, double) n);
>
> These two lines declare _two_ abs() functions, one taking a long argument,
> another takes extended. However, for types byte, short and int, first
> version is called (and argument is cast to long), and for float and
> double, the second version is called. This is essentially the same as
> if there was a set of overloaded functions:
>
>     long abs(long n);
>     long abs(int n) { return abs(cast(long) n); }
>     long abs(short n) { return abs(cast(long) n); }
>     long abs(byte n) { return abs(cast(long) n); }
>
> Only shorter, and the compiler might decide not to use inline wrappers,
> but to resolve ambiguity just by looking at the list of possible
> types for each argument.
>
> What do you think?
>
> P.S. The same could be applied to return type as well...
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:adg33m$1m4h$1@digitaldaemon.com...
> I was thinking along the same lines, but I couldn't get it into words and you brought it up. I think it's an excellent idea.
>
Fix
The only problem I can see with this is that we don't want to give the
programmer a typing overload.

>
> What about these problems to solve,
>
> Declared in module 1
> long abs(long cast(byte, short, int) n);
>
> Declared in module 2
> extended abs(extended cast(int ,float, double) n);
>
> So I suppose in this situtation a complier error message would be
triggered,
> if two overloads shared the same type. But a better Idea would be to use module 2 for the int in it's local space.
>
> It'd also be good to have an alternative method to save on typing
>
> extended abs(extended allbut(int) n); //Would do everything except int
> values
>
> Extending some of my orignal ideas.
> If a function is deleared without a in built cast it becomes default. You
> can overwrite (not overload) a default function for local use (like you
can
> already). You cannot however overwrite a default function twice in the
same
> local space.
>
> If a function contains the cast word then it is explictly saying to
overload
> those values. You can overwrite (not overload) a cast function for local use. You cannot however overwrite a cast for the same types function twice in the same local space.
>
> ie 1 -Wrong
> Module 1
> long abs(long n); (default function) //OK works in local space
> long abs(int n); (default function) //ERROR, cannot overwrite must cast
>
> ie 2 -Correct
> Module 1
> long abs(long n); //(default function) //OK works in local space
>
> Module 2
> long abs(int n); //(default function) //OK works in local space
>
> ie 3
> Module 1
> long abs(long n); //(default function) //OK works in local space
>
> Module 2
> long abs(int n); //(default function)
> long abs(int cast(int, long) n); //(cast function)
> long abs(int cast(int, double) n); //ERROR, ambiguus choice available
>
> ie 3
> Module 1
> long abs(long n); //(default function) //OK works in local space
> long abs(int cast(int, double) n); //OK works in local space
>
> Module 2
> long abs(int n); //(default function)
> long abs(int cast(int, long) n); //(cast function)
>
> You get the idea though.
> That's my solution to that problem, you may have already though of that
far
> ahead of me.
>
> So of course using your method (which I happen to like), does make things
> more tricky.
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:adfleq$175n$1@digitaldaemon.com...
> > Just a thought to extend the idea further.
> >
> > What if it would be possible to tell the compiler, arguments of which type does this function expect. The syntax could be something like this:
> >
> >     long abs(long cast(byte, short, int) n);
> >     extended abs(extended cast(float, double) n);
> >
> > These two lines declare _two_ abs() functions, one taking a long
argument,
> > another takes extended. However, for types byte, short and int, first version is called (and argument is cast to long), and for float and double, the second version is called. This is essentially the same as if there was a set of overloaded functions:
> >
> >     long abs(long n);
> >     long abs(int n) { return abs(cast(long) n); }
> >     long abs(short n) { return abs(cast(long) n); }
> >     long abs(byte n) { return abs(cast(long) n); }
> >
> > Only shorter, and the compiler might decide not to use inline wrappers,
> > but to resolve ambiguity just by looking at the list of possible
> > types for each argument.
> >
> > What do you think?
> >
> > P.S. The same could be applied to return type as well...
> >
> >
>
>