"James Widman" <james@jwidman.com> wrote in message news:james-F9B8BE.03385009062004@digitalmars.com...
> In article <ca5fls$2oi$1@digitaldaemon.com>,
>  Arcane Jill <Arcane_member@pathlink.com> wrote:
> > >1) is everybody ok with that lie?  I don't think we should be, because it will inhibit people's ability to understand code.
> >
> > No, this is fine. It's completely comprehensible. It's a void function which takes an out parameter. It reads fine.
>
> I think I'm ok with the concept of "out" parameters in general: you pass an argument to a function, and the function assigns something to it.
>
> So for:
>
> class A
>     {
>     void opCast(out int x) { x = 3; }
>     }
>
> void f(A a)
>     {
>     int i;
>     a.opCast(i);     // OK; opCast will assign a value to "i".
>
>
> // XXX But as for this:
>     i = cast(int)a;  // opCast returns void...so for this to work there
>                      // must be a hidden variable (the "out" argument)
>                      // which will implicitly be used as if it were the
>                      // cast operator's return value.  Should this work
>                      // in general for void functions that take a single
>                      // "out"?
>     }
>
>
> > >IMHO, a return type of "void" should mean "this function returns void".
> >
> > There's nothing wrong with a void function taking out parameters.
>
> Agreed -- but because of the way the cast operator is used, it looks to me like the compiler would have to behave as if opCast had been declared as returning non-void -- that's the "lie" I referred to earlier.
>
> Or it could just be that I'm terribly confused. :-) Is there some relevant part of the spec that I should review?
>
> > The syntax doesn't matter. All that matters is BEING ABLE TO DO IT AT ALL.I suggest we let Walter choose the syntax. I don't believe that any of us
really
> > care about the syntax all that much.
>
> Oh come on; if the syntax really didn't matter, we could just copy the way C++ does conversion operators. :-)   ("Not that there's anything wrong with that...")
>
> I think the clean design of the syntax is one of the main reasons why D code is so much more readable than the equivalent C++ -- take templates, for example.
>
> Now, of course Walter's going to choose the syntax. But *everyone's* going to be stuck with it in the months and years to come (i.e., users, compiler writers, and language support tool-writers), so I think it pays to ask about these things.
>
>
> > Let's just be unequivocal about the fact
> > that this is a desirable feature, whatever the syntax.
>
> It's definitely a desirable feature. :-)
>
> I'm sorry; I really don't want to be the nit-picker in the crowd.  But in general, syntax issues really do matter. It affects the way language features will be used in the future, and it can affect the ease of implementation.
>
> Now so far, I think I like Matthew's suggestion best, but FWIW, here's my stab at it:
>
> class B
>     {
>     opCast(int) { return 0; }
>     opCast(real) { return 0.0; }
>     }
>
> Notes:
>
> 1) Any way you slice it, the addition of this feature implies an overload on the return type.  Now in general, special cases should scare us, but since we're specifying the return type with /each invocation/, and that type (and the type of the cast-from object) is all we need to select the right overload, we should be scared less:
>
> void f(B b)
>     {
>     int i = cast(int)b;   // it's pretty obvious which overload
>     real r = cast(real)b; // we're selecting in both cases.
>
> 2) But since it is, after all, a special case, we should choose a syntax that shouts "I am a special case!" as loudly as possible. So "opCast" comes first in the declaration, then (parenthesized) return type, then function body.

Exactly correct. That's what I tried to achive with my suggestions. I'm happy with anything that marks this specialness; I certainly don't like the out param version for this reason

In article <ca6g4o$1igp$1@digitaldaemon.com>,
 Arcane Jill <Arcane_member@pathlink.com> wrote:
> Maybe the only irritation here is that I named the dummy argument. Compare:
> 1)  int opCast(int dummy);
> 2)  int opCast(int);
> 
> Now (2) looks nicer, I grant you. It just won't compile - though of course,
> Walter may be able to change that, for this special case only. But
> personally, I
> don't mind naming a dummy parameter. It doesn't bother me at all. It makes it
> clear that this IS a normal function,
<snip>

Well, almost normal. There is one restriction though: a declaration like this is Right Out (TM):

class A
    {
    real opCast(int x) { return 0.0; }
    }

...So the return type must match the parameter type.  If we leave the return type out of the syntax, that's one less type equivalence check that the compiler would have to do.  There are probably some other checks/diagnostics that can be avoided if we leave out the dummy name. (e.g., "name hides previous declaration" -- actually, that's probably the only one.  Still, one less name lookup.)  Less clutter for users, less clutter for compilers.

If I missed something, then somebody whack me with a cluestick. :-)

James

James Widman wrote:

> <snip>
> 
> Well, almost normal. There is one restriction though: a declaration like this is Right Out (TM): 
> 
> class A
>     {
>     real opCast(int x) { return 0.0; }
>     }
> 
> ...So the return type must match the parameter type.  If we leave the return type out of the syntax, that's one less type equivalence check that the compiler would have to do.  There are probably some other checks/diagnostics that can be avoided if we leave out the dummy name. (e.g., "name hides previous declaration" -- actually, that's probably the only one.  Still, one less name lookup.)  Less clutter for users, less clutter for compilers. 
> 
> If I missed something, then somebody whack me with a cluestick. :-)

It's not a big problem because normal type coersion rules can resolve this issue easily enough.

If someone tries to do something freaky like char[] opCast(Object o), the types won't match, and the compiler will correctly complain.

It'd be nice if the compiler enforced that the dummy argument matched the return type exactly, but only because it would make the error message nicer.

 -- andy