"anderson" <anderson@firestar.com.au> wrote in message news:adg33m$1m4h$1@digitaldaemon.com...

> 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.

If we import both modules into a third one, that we'd have to resolve the naming conflict, using full names anyhow:

    int a;
    module1.abs(a);
    module2.abs(a);

If we define AND call abs() from module2, then local declaration shadows
out the one from module1. So you won't be able to call abs(byte), for
example, unless you provide the full name - module1.abs(byte).

> 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

Or it could be:

    extended abs(extended !cast(int) n);

> 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


I'd let it be there, just for compatibility, and preserve the current semantics. IMO, it's better to think of cast() as of addition to rather than replacement of current schema of function overloading.

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

I think this should be an error. IMO, the best idea is to consider such declaration semantically equal to this:

    long abs(int);
    long abs(long);

Since we already have abs(int) in this module, it should be
forbidden.

By the way, since n is already int, why list it in the cast clause? It should be implicit.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:adg79p$1r3c$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:adg33m$1m4h$1@digitaldaemon.com...
>
> > 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.
>
> If we import both modules into a third one, that we'd have to resolve the naming conflict, using full names anyhow:
>
>     int a;
>     module1.abs(a);
>     module2.abs(a);
>
> If we define AND call abs() from module2, then local declaration shadows
> out the one from module1. So you won't be able to call abs(byte), for
> example, unless you provide the full name - module1.abs(byte).
>
> > 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
>
> Or it could be:
>
>     extended abs(extended !cast(int) n);

Good Idea

> > 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
>
>
> I'd let it be there, just for compatibility, and preserve the current semantics. IMO, it's better to think of cast() as of addition to rather than replacement of current schema of function overloading.
>
> > Module 2
> > long abs(int n); //(default function)
> > long abs(int cast(int, long) n); //(cast function)
>
> I think this should be an error. IMO, the best idea is to consider such declaration semantically equal to this:
>
>     long abs(int);
>     long abs(long);

You right,

I did mean,
long abs(int n); //(default function)
long abs(int cast(double, long) n); //(cast function)

I which case there shouldn't be any problems.

So as a general example, the following should occure

M1 (effected only by 1)
1 int abs(int);

M2  (effected only by 2,3)
2 int abs(int);
3 int abs(double cast(double));

M3 (effected only by 4,5)
4 int abs(int);
5 int abs(int cast(long));

M4 (effected only by 4,5,3)
import M1
import M2
import M3

Because It's good to encourage low coupling and high coheiesion.

Also with scoping, sometimes it's nessary to overload a function that's outside the scope of the present model. For example a sorting algoithm that uses ">".

This is my suggestion, which is not very neat and you may have a better idea.

M1 (effected only by 1)
1 int abs(int);

M2  (effected only by 2,3)
2 int abs(int);
3 int abs(double cast(double));

M3 (effected only by 4,5)
4 int abs(int);
5 int abs(int cast(long));

M4 (effected only by 4,5,3)
import M1
import M2
6 int abs(int cast(long)) //Overwrites 5
import M3 (all function called from this one that use abs(long) are effected
by 6)




> Since we already have abs(int) in this module, it should be
> forbidden.
>
> By the way, since n is already int, why list it in the cast clause? It should be implicit.
>
>
>
>

But that does not seem like a good idea to me.

> M1 (effected only by 1)
> 1 int abs(int);
>
> M2  (effected only by 2,3)
> 2 int abs(int);
> 3 int abs(double cast(double));
>
> M3 (effected only by 4,5)
> 4 int abs(int);
> 5 int abs(int cast(long));
>
> M4 (effected only by 4,5,3)
> import M1
> import M2
> 6 int abs(int cast(long)) //Overwrites 5
> import M3 (all function called from this one that use abs(long) are
effected
> by 6)
>

"anderson" <anderson@firestar.com.au> wrote in message news:adcimp$2li4$1@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message
> > A headache for both the compiler (to find out such cases), and the developer. Okay, so this case is simple, but call to foo() might have happened in a complex expression, and due to the weak nature of D type system, many type conversions could happen, so it is hard to tell the desired type for the return value of foo() at some point.
> Ok, seems resonable. So it's D fault for having a weak type system for returns types. And you like D having weak return types?

What Pavel's referring to are the default integral promotion rules, which in D are just like in C. Without them, there is too much casting necessary.

Also, if function return types were overloadable, in order to compile an expression with multiple overloaded function calls in it, the compiler will have to try every combinatoric assortment of those functions trying to find the "best" match. I don't think the result of that will be pleasing <g>.

Have you read the rest of the suggestions? Explicit which changed into Pavel's Cast like so,

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

That way there is no ambiguity and no extra casting nessary.
The initial one is the default, while other are explicit. By explicit I mean
must be one of the things in cast to be accepted. Of coarse there would
still be some problems programming the complier, but that's your field not
mine.


"Walter" <walter@digitalmars.com> wrote in message news:ae7v8h$a9d$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:adcimp$2li4$1@digitaldaemon.com...
> > "Pavel Minayev" <evilone@omen.ru> wrote in message
> > > A headache for both the compiler (to find out such cases), and the developer. Okay, so this case is simple, but call to foo() might have happened in a complex expression, and due to the weak nature of D type system, many type conversions could happen, so it is hard to tell the desired type for the return value of foo() at some point.
> > Ok, seems resonable. So it's D fault for having a weak type system for returns types. And you like D having weak return types?
>
> What Pavel's referring to are the default integral promotion rules, which
in
> D are just like in C. Without them, there is too much casting necessary.
>
> Also, if function return types were overloadable, in order to compile an expression with multiple overloaded function calls in it, the compiler
will
> have to try every combinatoric assortment of those functions trying to
find
> the "best" match. I don't think the result of that will be pleasing <g>.
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:ae96c2$24ol$1@digitaldaemon.com...
> Have you read the rest of the suggestions? Explicit which changed into Pavel's Cast like so,
>
>     long abs(double n);
>     long abs(long cast(byte, short, int) n);
>     extended abs(extended cast(float) n);
>
> That way there is no ambiguity and no extra casting nessary.
> The initial one is the default, while other are explicit. By explicit I
mean
> must be one of the things in cast to be accepted. Of coarse there would still be some problems programming the complier, but that's your field not mine.

Yes, that handles overloading by argument, but not by function return value.

The same can be applied,

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

I think Paval mentioned that.

"Walter" <walter@digitalmars.com> wrote in message news:ae9h0g$2hal$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:ae96c2$24ol$1@digitaldaemon.com...
> > Have you read the rest of the suggestions? Explicit which changed into Pavel's Cast like so,
> >
> >     long abs(double n);
> >     long abs(long cast(byte, short, int) n);
> >     extended abs(extended cast(float) n);
> >
> > That way there is no ambiguity and no extra casting nessary.
> > The initial one is the default, while other are explicit. By explicit I
> mean
> > must be one of the things in cast to be accepted. Of coarse there would still be some problems programming the complier, but that's your field
not
> > mine.
>
> Yes, that handles overloading by argument, but not by function return
value.
>
>

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ad5iq8$1ri2$1@digitaldaemon.com...
> This is new to me. I just checked the code generated by Microsoft C/C++ in
C
> mode. It allocates an anonymous stack variable for the return value in the calling code for each function call (not each invocation), which is perfectly reentrant. Small structs are returned in registers. I checked
GCC
> too, and it also allocates the structure on the stack in the calling code. The behaviour you describe above sounds like a compiler bug to me.

It's the way C compilers used to work. -Walter