www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The purpose of opCast?

reply Derek <derek psych.ward> writes:
I know this is a "squeaky wheel", but has anyone found a good reason to use
the current opCast overloading? To me it still seems like a half-baked idea
that does nobody any good yet. I suspect its just that I don't understand
what it was designed to do (read: what is the problem it is trying to
solve).

-- 
Derek
Melbourne, Australia
Feb 18 2005
next sibling parent reply John Demme <me teqdruid.com> writes:
Although I haven't found a good use for it yet, it's a matter of 
symmetry.  In D, I can overload *all* of the operators that primitives 
can use, and thusly replace a primitive with a class with very little 
effort.  Since primitives can be cast, there should be an operator 
overload for it.

Or at least that's my opinion.

John

Derek wrote:
 I know this is a "squeaky wheel", but has anyone found a good reason to use
 the current opCast overloading? To me it still seems like a half-baked idea
 that does nobody any good yet. I suspect its just that I don't understand
 what it was designed to do (read: what is the problem it is trying to
 solve).
 

Feb 18 2005
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
John Demme schrieb:
 Although I haven't found a good use for it yet, it's a matter of 
 symmetry.  In D, I can overload *all* of the operators that primitives 
 can use, and thusly replace a primitive with a class with very little 
 effort.  Since primitives can be cast, there should be an operator 
 overload for it.

But at best, it is a half-hearted attempt to cover up the asymmetry without really solving it. Primitives can be cast to various types. opCast can be overloaded only for one target type. Primitives can be casted implicitely. opCast only works for explicit casts. The easiest solution for the first restriction could be learned from C++: change the specs in such a way that opCast takes one dummy argument of the same type as the return type. ... cast(sometype)(someobject) ... would then be equivalent to sometype dummyvar; ... someobject.opCast(dummyvar) ... For the second restriction the biggest hurdle might be to convince Walter that implicit casting is essential for the extensibility of the language. So far, he seems to be strictly against implicit casting (except for the builtin types, of course.)
Feb 19 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 19 Feb 2005 11:53:02 +0100, Norbert Nemec  
<Norbert Nemec-online.de> wrote:
 John Demme schrieb:
 Although I haven't found a good use for it yet, it's a matter of  
 symmetry.  In D, I can overload *all* of the operators that primitives  
 can use, and thusly replace a primitive with a class with very little  
 effort.  Since primitives can be cast, there should be an operator  
 overload for it.

But at best, it is a half-hearted attempt to cover up the asymmetry without really solving it. Primitives can be cast to various types. opCast can be overloaded only for one target type. Primitives can be casted implicitely. opCast only works for explicit casts.

Some can, to some types, this seems to have been decided on a case by case basis. I vaguely remember that some of these cases bothered me, but I can't remember which ones exactly.. maybe someone else can?
 The easiest solution for the first restriction could be learned from  
 C++: change the specs in such a way that opCast takes one dummy argument  
 of the same type as the return type.
 	... cast(sometype)(someobject) ...
 would then be equivalent to
 	sometype dummyvar;
 	... someobject.opCast(dummyvar) ...

IMO this is a 'hack', surely we can do better, that is, if we want to do this at all. I understand that overloading by return type has 'issues' of complexity, however, if the cast was always explicit... I realise people don't like 'special-case' behaviour i.e. making opCast the only thing that overloads by return type... Does it make sense, is it possible, to allow overloads by return type for everything, giving an error where it's indeterminate and requiring and explicit cast.
 For the second restriction the biggest hurdle might be to convince  
 Walter that implicit casting is essential for the extensibility of the  
 language. So far, he seems to be strictly against implicit casting  
 (except for the builtin types, of course.)

It's the classic trade off, implicit vs explicit, ease-of-use non-obvious behaviour vs verbose obvious behaviour. Everyone draws the line in a different place. The difference between a class and primitives is that Walter can define casts that should be implicit and ones that shouldn't for primitives. He has no way of doing the same with classes, so takes the safest option making them all explicit. All FWICS and IMO of course. Regan
Feb 20 2005
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Regan Heath schrieb:
 Does it make sense, is it  possible, to allow overloads by return type for
everything, giving 
 an  error where it's indeterminate and requiring and explicit cast.

I think, it would make parsing a mess. Currently, the type of an expression can always be determined bottom up: determine the types of the leaves and from there construct the type of the whole expression deterministically. If you break this up, the language becomes a mess. (C/C++ had a few exceptions which were cleaned out in D)
 For the second restriction the biggest hurdle might be to convince  
 Walter that implicit casting is essential for the extensibility of 
 the  language. So far, he seems to be strictly against implicit 
 casting  (except for the builtin types, of course.)

It's the classic trade off, implicit vs explicit, ease-of-use non-obvious behaviour vs verbose obvious behaviour. Everyone draws the line in a different place.

Of course. Language design consists of drawing lines and making decisions. Neither language design nor any other art mix too well with democracy. Still, since the artwork 'D' is still in progress, the lines that have been drawn before might slowly evolve...
Feb 20 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Norbert Nemec wrote:
 Regan Heath schrieb:
 
 Does it make sense, is it  possible, to allow overloads by return type 
 for everything, giving an  error where it's indeterminate and 
 requiring and explicit cast.


Interesting thought. At first sight, the compiler could surely use the return type as well as argument types in overload resolution. Or could it? Are there any strong reasons for not doing this? OTOH, is it really needed? Or what reasons are there against it?
Feb 21 2005
parent reply Derek <derek psych.ward> writes:
On Mon, 21 Feb 2005 12:16:13 +0200, Georg Wrede wrote:

 Norbert Nemec wrote:
 Regan Heath schrieb:
 
 Does it make sense, is it  possible, to allow overloads by return type 
 for everything, giving an  error where it's indeterminate and 
 requiring and explicit cast.


Interesting thought. At first sight, the compiler could surely use the return type as well as argument types in overload resolution. Or could it? Are there any strong reasons for not doing this? OTOH, is it really needed? Or what reasons are there against it?

The main one seems to be, what would happen if someone coded a function call but did not assign the return to anything? How would the compiler know which signature to use if it had to use return-type as a determinate? eg. int foo(char a) { . . . return 1;} real foo(char a) { . . . return 1.0; } void bar(int x) { . . . } void bar(real x) { . . . } foo('x'); // Does this return an int or real? bar( foo('y') ); // Which 'bar' is to be called? To counter this, one could make the rule that every call to a function must either assign the result or indicate to the compiler which return type is being ignored/required. This would help make programs more robust and help readers know the coder's intentions better. For example... cast(int)foo('x'); // Call the 'int' version and ignore the result. bar( cast(real)foo('y') ); // Call the 'real' version of foo and bar. -- Derek Melbourne, Australia
Feb 21 2005
parent reply xs0 <xs0 xs0.com> writes:
 The main one seems to be, what would happen if someone coded a function
 call but did not assign the return to anything? How would the compiler know
 which signature to use if it had to use return-type as a determinate?

Well, that's not the only "main" issue, imho.. For example, consider: int mysqrt(double a) { return floor(sqrt(a)); } double eval_some_cost(...) { double cost=sqrt(..); if (something) cost*=1.3; return cost; } Now, this works fine and all. But, I (or my co-worker) can decide sometime in the future that there should also be a double mysqrt(double) returning the unrounded square root (or even something completely different, but that is bad style, I guess). The problem is that without any change in either the int version or in eval_some_cost(), the code will produce different results. This is most probably the reason why ambiguous function calls are not allowed and you need to be explicit which version you want to use.
 For example...
    cast(int)foo('x');  // Call the 'int' version and ignore the result.
    bar( cast(real)foo('y') ); // Call the 'real' version of foo and bar.

Hmm, but there's no casting, so why use the cast() operator? I'd like better something along the lines of foo:int('x'); bar(foo:real('y')); And cast(type)obj can almost be directly translated to obj.opCast:type() (almost because implicit casts should still be allowed when there's no ambiguity). Ambiguity should be defined differently for return types, though - the above problem is still not solved, even if there is an exact match (actually, precisely because of the exact match). So, I'd say that if there are return types A and B, and either can be implicitly casted to the other, the caller should be forced to specify which is the right one when using either. That's ok, though; even if you write A a=func(), it actually doesn't mean that func() should return something of type A, it just means that you'd like the compiler to implicitly cast it to A. This logic is actually the same as with double a=2/3 -- you'll still get 0, because the casting gets done on assignment, not evaluation.. xs0
Feb 21 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
     double cost=sqrt(..);

should of course be double cost=mysqrt(..); :) xs0
Feb 21 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 21 Feb 2005 14:04:00 +0100, xs0 <xs0 xs0.com> wrote:
     double cost=sqrt(..);

should of course be double cost=mysqrt(..); :)

I really should read all threads before answering.. regardless that wont compile. Regan
Feb 21 2005
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 21 Feb 2005 14:03:04 +0100, xs0 <xs0 xs0.com> wrote:
 The main one seems to be, what would happen if someone coded a function
 call but did not assign the return to anything? How would the compiler  
 know
 which signature to use if it had to use return-type as a determinate?

Well, that's not the only "main" issue, imho.. For example, consider: int mysqrt(double a) { return floor(sqrt(a)); } double eval_some_cost(...) { double cost=sqrt(..);

I assume the above line is supposed to be double cost=mysqrt(..); ? if so, it doesn't compile, return type is wrong.
      if (something)
          cost*=1.3;

      return cost;
 }

 Now, this works fine and all.

Can you give an example which compile, so I can mess with it :)
 But, I (or my co-worker) can decide sometime in the future that there  
 should also be a double mysqrt(double) returning the unrounded square  
 root (or even something completely different, but that is bad style, I  
 guess). The problem is that without any change in either the int version  
 or in eval_some_cost(), the code will produce different results. This is  
 most probably the reason why ambiguous function calls are not allowed  
 and you need to be explicit which version you want to use.

Consider this, existing, similar problem: class Parent { void foo(long a) { printf("parent: foo: long\n"); } } class Child : Parent { //uncomment this line //void foo(int a) { printf("child: foo: int\n"); } } void main() { Child c = new Child(); long a = 5; c.foo(a); } This issue is caused by name resolution matching the child function with implicit conversion. In other words, implicit conversion causes the problem, and it's a seperate issue to solve, adding this new explicit function selection will not add new sources of bugs, they're already there.
 For example...
    cast(int)foo('x');  // Call the 'int' version and ignore the result.
    bar( cast(real)foo('y') ); // Call the 'real' version of foo and bar.

Hmm, but there's no casting, so why use the cast() operator?

Because it has basically the same meaning.
 I'd like better something along the lines of

 foo:int('x');
 bar(foo:real('y'));

I think we can avoid a 'new' syntax by using an existing one, I think cast(x) will be commonly understood.
 And cast(type)obj can almost be directly translated to obj.opCast:type()  
 (almost because implicit casts should still be allowed when there's no  
 ambiguity). Ambiguity should be defined differently for return types,  
 though - the above problem is still not solved, even if there is an  
 exact match (actually, precisely because of the exact match).

Agreed, however the problem already exists as shown in example #1.
 So, I'd say that if there are return types A and B, and either can be  
 implicitly casted to the other, the caller should be forced to specify  
 which is the right one when using either.

Agreed, but it's not the way D works currently.
 That's ok, though; even if you write A a=func(), it actually doesn't  
 mean that func() should return something of type A, it just means that  
 you'd like the compiler to implicitly cast it to A.

Yep, this is how D works currently.
 This logic is actually the same as with double a=2/3 -- you'll still get  
 0, because the casting gets done on assignment, not evaluation..

Yep, if this was an error the bug would be spotted. This whole issue comes down to where you draw the line, where you balance convenience vs pedanticism. (if that aint a word it should be). Walter has drawn it in one place, almost everyone disagrees in some way, large or small. Regan
Feb 21 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
 Can you give an example which compile, so I can mess with it :)

The point wasn't to compile it :) If you really want to, you can probably just return (int)sqrt(..) or something..
 The problem is that without any change in either the int version  
 or in eval_some_cost(), the code will produce different
 results. This is  most probably the reason why ambiguous function 
 calls are not allowed  and you need to be explicit which version you 
 want to use.

Consider this, existing, similar problem: class Parent { void foo(long a) { printf("parent: foo: long\n"); } } class Child : Parent { //uncomment this line //void foo(int a) { printf("child: foo: int\n"); } } void main() { Child c = new Child(); long a = 5; c.foo(a); }

Yup, it is similar, but I think that in this case, Parent.foo will still be called (because long can't be implicitly cast to int?). And even if you switched int and long, it's not the quite the same - Child is a new class with a new contract and whatnot.. But yes, in any case, overloading methods with implicitly castable types (both the return type and the parameters) is asking for trouble. Still, overloading parameter types is an issue that's present in other languages as well (like C++ and Java), so I guess people (i.e. me) are more used to it, while overloading on return type is far less common..
 Hmm, but there's no casting, so why use the cast() operator?

Because it has basically the same meaning.

How does it have the same meaning? Normally, you cast() something to make it one type from another type. If you select some specific return type, you'd already get that type as the result, so you wouldn't want to cast it. I'd certainly read cast(int)func(params) as func _not_ returning int.
 Agreed, but it's not the way D works currently.

Yup, currently you can't overload just on return types :)
 This whole issue comes down to where you draw the line, where you 
 balance  convenience vs pedanticism. (if that aint a word it should be). 
 Walter has  drawn it in one place, almost everyone disagrees in some 
 way, large or  small.

I certainly don't disagree with Walter; actually I think D is the best language I've ever seen (at least in the compiled-to-native-code category). Well, considering how opCast is the only problem where not having return-type-overloads is really an issue, perhaps it could just get special treatment and the problem'd be solved? class A { cast(T : int) { return ...; } cast(T : double) { return ...; } } or something.. looks obvious to me :) (T is just dummy, of course, but the syntax indicates specialization of cast for different types, much like with templates) xs0
Feb 21 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Feb 2005 01:26:44 +0100, xs0 <xs0 xs0.com> wrote:
 Can you give an example which compile, so I can mess with it :)

The point wasn't to compile it :) If you really want to, you can probably just return (int)sqrt(..) or something..

If it doesn't compile and you're trying to show something that 'could' happen then it's an invalid example.
 The problem is that without any change in either the int version


 results. This is  most probably the reason why ambiguous function  
 calls are not allowed  and you need to be explicit which version you  
 want to use.

class Parent { void foo(long a) { printf("parent: foo: long\n"); } } class Child : Parent { //uncomment this line //void foo(int a) { printf("child: foo: int\n"); } } void main() { Child c = new Child(); long a = 5; c.foo(a); }

Yup, it is similar, but I think that in this case, Parent.foo will still be called (because long can't be implicitly cast to int?).

Wrong.
 And even if you switched int and long, it's not the quite the same -  
 Child is a new class with a new contract and whatnot.. But yes, in any  
 case, overloading methods with implicitly castable types (both the  
 return type and the parameters) is asking for trouble. Still,  
 overloading parameter types is an issue that's present in other  
 languages as well (like C++ and Java), so I guess people (i.e. me) are  
 more used to it, while overloading on return type is far less common..


 Hmm, but there's no casting, so why use the cast() operator?


How does it have the same meaning? Normally, you cast() something to make it one type from another type. If you select some specific return type, you'd already get that type as the result, so you wouldn't want to cast it. I'd certainly read cast(int)func(params) as func _not_ returning int.

It has the same meaning as casting a parameter to force the compiler to select the correct overload. Sure, casting a parameter does actually cast the parameter, but so does casting a return value. The only difference is the order it happens in.
 Agreed, but it's not the way D works currently.

Yup, currently you can't overload just on return types :)

That isn't what I meant.
 This whole issue comes down to where you draw the line, where you  
 balance  convenience vs pedanticism. (if that aint a word it should  
 be). Walter has  drawn it in one place, almost everyone disagrees in  
 some way, large or  small.

I certainly don't disagree with Walter; actually I think D is the best language I've ever seen (at least in the compiled-to-native-code category). Well, considering how opCast is the only problem where not having return-type-overloads is really an issue, perhaps it could just get special treatment and the problem'd be solved?

Perhaps. A more generic soln would be more useful however.
 class A {
     cast(T : int) { return ...; }
     cast(T : double) { return ...; }
 }

 or something.. looks obvious to me :) (T is just dummy, of course, but  
 the syntax indicates specialization of cast for different types, much  
 like with templates)

This is a hack. I think we can do better. Regan
Feb 21 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
 If it doesn't compile and you're trying to show something that 'could'  
 happen then it's an invalid example.

Well, I didn't specify which floor() and sqrt() get called, so one could argue that the example was valid? :)
 Yup, it is similar, but I think that in this case, Parent.foo will 
 still  be called (because long can't be implicitly cast to int?).

Wrong.

My mistake then.. Although I think it should be the case, according to http://www.digitalmars.com/d/type.html (which doesn't list long in integer promotions, true, but I was extrapolating the int case).
 It has the same meaning as casting a parameter to force the compiler to  
 select the correct overload. Sure, casting a parameter does actually 
 cast  the parameter, but so does casting a return value. The only 
 difference is  the order it happens in.

Well, you make it sound as if you're trying to work around a bug in the compiler (which would be its complaining), but you're really just producing an exact match. Casting a return value, otoh, happens _after_ the function returns, so it can't be used for the same purpose... And consider the case where you'd want the double version, but you'd like to also cast it to int: cast(int)(cast(double)func(3)) ?
 Yup, currently you can't overload just on return types :)

That isn't what I meant.

So what did you mean?
 Well, considering how opCast is the only problem where not having  
 return-type-overloads is really an issue, perhaps it could just get  
 special treatment and the problem'd be solved?

Perhaps. A more generic soln would be more useful however.

Well, it depends on what you consider useful, I guess. I find it rather useful if the language doesn't contain features which complicate things without any real benefit.. I mean, what's the real difference between cast(int)something and something.asInt()? The only reasonable case I can think of are templates, so you can use the same code both for classes that are something, and classes than can cast themselves as that same something (like a List or whatever). And in that respect, having multiple possible casts might be a good idea..
 This is a hack. I think we can do better.

Well, what is your better suggestion then? Your suggestion (cast(type)func) is imho much more of a hack. BTW, I wasn't suggesting a dummy parameter, which you already proclaimed a hack, merely a dummy type alias, which could possibly even be used with a mixin or something, so it wouldn't even be a dummy anymore. As in: cast(T: int) { return Something!(T).convert(this); } cast(T: double) { return Something!(T).convert(this); } xs0
Feb 21 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Feb 2005 02:12:27 +0100, xs0 <xs0 xs0.com> wrote:
 If it doesn't compile and you're trying to show something that 'could'   
 happen then it's an invalid example.

Well, I didn't specify which floor() and sqrt() get called, so one could argue that the example was valid? :)

If you had specified them, would it have compiled? If so, post the example here, if not...
 Yup, it is similar, but I think that in this case, Parent.foo will  
 still  be called (because long can't be implicitly cast to int?).


My mistake then.. Although I think it should be the case, according to http://www.digitalmars.com/d/type.html (which doesn't list long in integer promotions, true, but I was extrapolating the int case).

It doesn't say exactly what it does on that page, it probably should. I notice you don't try examples which are posted, I think you should, before commenting on them, it's a waste of time guessing what's going to happen.
 It has the same meaning as casting a parameter to force the compiler  
 to  select the correct overload. Sure, casting a parameter does  
 actually cast  the parameter, but so does casting a return value. The  
 only difference is  the order it happens in.

Well, you make it sound as if you're trying to work around a bug in the compiler (which would be its complaining), but you're really just producing an exact match.

True, however I'm also specifying the overload I want, because the compiler cannot read my mind and I doesn't guess (thank Bob).
 Casting a return value, otoh, happens _after_ the function returns, so  
 it can't be used for the same purpose...

I disagree. As I said, I'm explicitly specifying the overload I mean.
 And consider the case where you'd want the double version, but you'd  
 like to also cast it to int:

 cast(int)(cast(double)func(3))

So you're saying you have: int func(int a) {} double func(int a) {} void main() { int a; a = func(); } and you want to call the double version, right? If so, then yes, your syntax looks fine.
 Yup, currently you can't overload just on return types :)


So what did you mean?

Your original comment was "So, I'd say that if there are return types A and B, and either can be implicitly casted to the other, the caller should be forced to specify which is the right one when using either." I replied: "Agreed, but it's not the way D works currently." Turns out, I was wrong, D does work this way currently. Your comment: "Yup, currently you can't overload just on return types :)" has no bearing on this however, and wasn't what I meant, so I said that.
 Well, considering how opCast is the only problem where not having   
 return-type-overloads is really an issue, perhaps it could just get   
 special treatment and the problem'd be solved?


Well, it depends on what you consider useful, I guess. I find it rather useful if the language doesn't contain features which complicate things without any real benefit.. I mean, what's the real difference between cast(int)something and something.asInt()?

As I said above, when casting to cause an exact match I am explicitly specifying the overload I want to use, because the compiler cannot read my mind and doesn't guess. The other is converting to an int, sure, the cast does this, but, when used to select an overload the intent is different, the fact that it's converting (which it might not be, consider int->long) is secondary.
 The only reasonable case I can think of are templates, so you can use  
 the same code both for classes that are something, and classes than can  
 cast themselves as that same something (like a List or whatever). And in  
 that respect, having multiple possible casts might be a good idea..

Classes can be implicitly cast to their parent types, I believe. Is this what you're referring to? eg. class A {} class B : A {} void foo(A a) {} void main() { B b = new B(); foo(b); } no cast is required, even if you add... class A {} class B : A {} void foo(A a) { printf("A"); } void foo(B b) { printf("B"); } void main() { B b = new B(); A a = new A(); foo(a); foo(b); }
 This is a hack. I think we can do better.

Well, what is your better suggestion then?

cast(type)
 Your suggestion (cast(type)func) is imho much more of a hack.

You're welcome to think so. In the end Walter decides anyway.
 BTW, I wasn't suggesting a dummy parameter, which you already proclaimed  
 a hack, merely a dummy type alias, which could possibly even be used  
 with a mixin or something, so it wouldn't even be a dummy anymore. As in:

 cast(T: int)    { return Something!(T).convert(this); }
 cast(T: double) { return Something!(T).convert(this); }

That syntax does not seem obvious to me. Which is why I prefer cast(type), it has an obvious commonly understood meaning. Regan
Feb 21 2005
parent reply xs0 <xs0 xs0.com> writes:
 Well, I didn't specify which floor() and sqrt() get called, so one 
 could  argue that the example was valid? :)

If you had specified them, would it have compiled? If so, post the example here, if not...

What kind of questions is that? Are you suggesting you're not sure whether "return floor(sqrt(a))" can ever be a valid function body? And I can't produce a compilable example, because the example included an overload on return type, which is not possible...
 I notice you don't try examples which are posted, I think you should,  
 before commenting on them, it's a waste of time guessing what's going 
 to  happen.

Like I said, I can't produce a compilable example (which I thought would be somewhat obvious from the nature of this thread, but I guess it isn't).
 True, however I'm also specifying the overload I want, because the  
 compiler cannot read my mind and I doesn't guess (thank Bob).

Maybe, but you're specifying the overload you want merely as a side-effect of casting parameters.
 Casting a return value, otoh, happens _after_ the function returns, 
 so  it can't be used for the same purpose...

I disagree. As I said, I'm explicitly specifying the overload I mean.

No, you're not.. You're just casting the return type. You can cast the return type now, so casting obviously doesn't mean you're trying to select an overload..
 So you're saying you have:
 
 int func(int a) {}
 double func(int a) {}
 
 void main() {
   int a;
   a = func();
 }
 
 and you want to call the double version, right?
 If so, then yes, your syntax looks fine.

Since you were so smart about compilable examples, I'm surprised you wrote an example that can't be compiled :P (Sorry, couldn't resist) I think you're not clear on how evaluation of expressions works, and that is the reason you think using cast for this would be fine. Let me try to explain. Let's focus just on ints and doubles. When you type cast(int)expression it's basically the same as if you called some compiler-provided function named, for example, cast_to_int(), so the above translates to cast_to_int(expression). That function has several overloads, in this case two (because I limited the example to two types): int cast_to_int(int value) { return value; } int cast_to_int(double value) { return ...; // the largest integer not less than value } Same goes for cast(double). Now, when you type f(cast(int)a, cast(double)b) it gets translated to f(cast_to_int(a), cast_to_double(b)) and NOT to f(a, b); // OY, COMPILER, I'M TALKING TO YOU! I WANT f(int,double) So, before the func() gets the parameters, they're already cast to the right types. Incidentally, that makes an exact match with one of the overloads of func(), so the compiler knows which one you meant. OTOH, if you write cast(int)func(a,b), it gets translated to cast_to_int(func(a,b)) From that it's obvious that casting is done _after_ the function is evaluated, so casting can't have an effect on which function is selected. Got it? (now don't start arguing I made this up; this is how it actually works (I wrote a parser or two in my life, so I know this))
 As I said above, when casting to cause an exact match I am explicitly  
 specifying the overload I want to use, because the compiler cannot read 
 my  mind and doesn't guess.

No, you're not specifying the overload, you're just casting the arguments, possibly producing an exact overload match..
 The other is converting to an int, sure, the cast does this, but, when  
 used to select an overload the intent is different, the fact that it's  
 converting (which it might not be, consider int->long) is secondary.

no, it isn't secondary, just the opposite (and casting int to long is converting, the first is 32 bits, the other is 64 bits). the only cast that doesn't do anything is actually casting a type to the same type.. (even if two types are the same length and casting doesn't change one bit, it will change the semantics of expressions; for example, if you cast int 3 to uint 3, you'll get exactly the memory contents; however, if you add 3000000000, you'll get a negative value in the first case and a positive value in the second case)
 The only reasonable case I can think of are templates, so you can use  
 the same code both for classes that are something, and classes than 
 can  cast themselves as that same something (like a List or whatever). 
 And in  that respect, having multiple possible casts might be a good 
 idea..

Classes can be implicitly cast to their parent types, I believe. Is this what you're referring to? eg.

Nope, I'm referring to something like this: class SomeClass(T) { void doSomething(T param) { List a=cast(List)param; // now do something with a } } This template will currently work for both Ts that are themselves Lists, and Ts that have opCast() that returns a List. But, opCast() can't be overloaded, and if you want it for something else, you have a problem..
 Well, what is your better suggestion then?

cast(type)

That's impossible (really, cast is not overload-selection-operator, it's casting-operator). Any other suggestions?
 cast(T: int)    { return Something!(T).convert(this); }
 cast(T: double) { return Something!(T).convert(this); }

That syntax does not seem obvious to me.

Why not? How would you suggest overloading opCast() if return-type overloading is not allowed (which is the case this suggestion is trying to cover, and I was just trying to show how T may not always be dummy)?
 Which is why I prefer cast(type), it has an obvious commonly understood  
 meaning.

Yes, I agree completely, it's just not what you understand it to be... xs0
Feb 22 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
xs0 wrote:
 That's impossible (really, cast is not overload-selection-operator, it's 
 casting-operator). Any other suggestions?

If we had overloading on return type, then in some situations we'd want some way to choose which return type to use. Using cast for this would seem natural. Of course, changing the semantics of cast may, for all I know, raise other issues.
Feb 22 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Feb 2005 10:20:33 +0100, xs0 <xs0 xs0.com> wrote:
 Well, I didn't specify which floor() and sqrt() get called, so one  
 could  argue that the example was valid? :)

If so, post the example here, if not...

What kind of questions is that? Are you suggesting you're not sure whether "return floor(sqrt(a))" can ever be a valid function body?

No.
 And I can't produce a compilable example, because the example included  
 an overload on return type, which is not possible...

No, your example didn't show one, you described one being added later. All I want is an example that compiles. Which should be possible.
 I notice you don't try examples which are posted, I think you should,   
 before commenting on them, it's a waste of time guessing what's going  
 to  happen.

Like I said, I can't produce a compilable example (which I thought would be somewhat obvious from the nature of this thread, but I guess it isn't).

See above.
 True, however I'm also specifying the overload I want, because the   
 compiler cannot read my mind and I doesn't guess (thank Bob).

Maybe, but you're specifying the overload you want merely as a side-effect of casting parameters.

No. If the compiler errors because it cannot pick the overload, then, by adding a cast I am selecting an overload, the fact that it casts/converts is the side effect. In other words the point/purpose of the cast changes depending on what it's used for. I think that, because the cast comes first, you're assuming it's the purpose, because the overload selection comes second it's a side effect. A side effect can occur first, just as the purpose can occur second.
 Casting a return value, otoh, happens _after_ the function returns,  
 so  it can't be used for the same purpose...


No, you're not.. You're just casting the return type. You can cast the return type now, so casting obviously doesn't mean you're trying to select an overload..

Yes, you can cast a return type now, now the purpose is to cast. Were it possible to cast to select an overload, then doing so would be the purpose. The purpose of cast now, is not always to convert, but sometimes to select an overload, the purpose changes depending on where it's used and why (by definition).
 So you're saying you have:
  int func(int a) {}
 double func(int a) {}
  void main() {
   int a;
   a = func();
 }
  and you want to call the double version, right?
 If so, then yes, your syntax looks fine.

Since you were so smart about compilable examples, I'm surprised you wrote an example that can't be compiled :P (Sorry, couldn't resist)

I find your comment petty. The example above cannot be compiled because it is an error, I was giving an example of an error case which your syntax would solve. The same is not true of your example, which was an example of 'before' the collision was added.
 I think you're not clear on how evaluation of expressions works, and  
 that is the reason you think using cast for this would be fine. Let me  
 try to explain.

I am not the only one, see Georg's reply.
 Let's focus just on ints and doubles. When you type cast(int)expression  
 it's basically the same as if you called some compiler-provided function  
 named, for example, cast_to_int(), so the above translates to  
 cast_to_int(expression). That function has several overloads, in this  
 case two (because I limited the example to two types):

 int cast_to_int(int value) {
     return value;
 }
 int cast_to_int(double value) {
     return ...; // the largest integer not less than value
 }

 Same goes for cast(double). Now, when you type

 f(cast(int)a, cast(double)b)

 it gets translated to

 f(cast_to_int(a), cast_to_double(b))

 and NOT to

 f(a, b); // OY, COMPILER, I'M TALKING TO YOU! I WANT f(int,double)

 So, before the func() gets the parameters, they're already cast to the  
 right types. Incidentally, that makes an exact match with one of the  
 overloads of func(), so the compiler knows which one you meant.

 OTOH, if you write cast(int)func(a,b), it gets translated to

 cast_to_int(func(a,b))

  From that it's obvious that casting is done _after_ the function is  
 evaluated, so casting can't have an effect on which function is  
 selected. Got it? (now don't start arguing I made this up; this is how  
 it actually works (I wrote a parser or two in my life, so I know this))

I understand everything you've said above, and I agree it works as you've said. But, the point you're missing is that the 'intent' of a statement is not necessarily the same as the effect generated by the compiler. In this case using a cast to "select an overload" is the intent of the programmer. The effect is that the "variable is converted", but, that is a side effect. This behaviour/method is generally accepted and understood by programmers, and extending it to include return values will be the same, generally accepted and understood. Further it requires no additional syntax and is easily parsable.
 As I said above, when casting to cause an exact match I am explicitly   
 specifying the overload I want to use, because the compiler cannot read  
 my  mind and doesn't guess.

No, you're not specifying the overload, you're just casting the arguments,

This is not my 'intent' it is simply the effect.
 possibly producing an exact overload match..

This is the intent.
 The other is converting to an int, sure, the cast does this, but, when   
 used to select an overload the intent is different, the fact that it's   
 converting (which it might not be, consider int->long) is secondary.

no, it isn't secondary, just the opposite (and casting int to long is converting, the first is 32 bits, the other is 64 bits).

It's not converting per-se, more extending and setting bits to 0.
 the only cast that doesn't do anything is actually casting a type to the  
 same type..

int -> uint makes no changes to the memory.
 (even if two types are the same length and casting doesn't change one  
 bit, it will change the semantics of expressions; for example, if you  
 cast int 3 to uint 3, you'll get exactly the memory contents; however,  
 if you add 3000000000, you'll get a negative value in the first case and  
 a positive value in the second case)

Sure, but as you and I have said, it makes no change to the memory. Regardless, this is beside the point, except to say that if a programmer uses a cast to select an overload they need to consider the effect the conversion will have, but, again, the conversion is secondary to the intent which is to select the overload.
 The only reasonable case I can think of are templates, so you can use   
 the same code both for classes that are something, and classes than  
 can  cast themselves as that same something (like a List or whatever).  
 And in  that respect, having multiple possible casts might be a good  
 idea..

Is this what you're referring to? eg.

Nope, I'm referring to something like this: class SomeClass(T) { void doSomething(T param) { List a=cast(List)param; // now do something with a } } This template will currently work for both Ts that are themselves Lists, and Ts that have opCast() that returns a List. But, opCast() can't be overloaded, and if you want it for something else, you have a problem..

Ok.
 Well, what is your better suggestion then?


That's impossible (really, cast is not overload-selection-operator, it's casting-operator). Any other suggestions?

No, this is the best method/soln I've heard so far.
 cast(T: int)    { return Something!(T).convert(this); }
 cast(T: double) { return Something!(T).convert(this); }


Why not?

Well.. it looks like a function, returning nothing, taking something called T which must be an int, if that's the case why not just go: cast(int) { .. } in which case it looks just like the c++ hack to me. So in short your example seems to be the c++ hack, with extra characters making it less clear (to me).
 How would you suggest overloading opCast() if return-type overloading is  
 not allowed

No idea, I'll think about this, if, return type overloading is officially "not going to happen, ever".
 (which is the case this suggestion is trying to cover, and

Ahh, then we're talking at cross puposes. I am suggesting overload on return values, using a cast. I think it's the best solution. If denied that, then I'll try and think of another solution.
 I was just trying to show how T may not always be dummy)?

I dont think it's any different to using a dummy, and using typeof(param) on it.
 Which is why I prefer cast(type), it has an obvious commonly  
 understood  meaning.

Yes, I agree completely, it's just not what you understand it to be...

It appears Georg agrees with me. Regan
Feb 22 2005
next sibling parent reply brad domain.invalid writes:
 
 If the compiler errors because it cannot pick the overload, then, by  
 adding a cast I am selecting an overload, the fact that it 
 casts/converts  is the side effect. In other words the point/purpose of 
 the cast changes  depending on what it's used for.
 

I haven't read the whole thread, but I think I get the general gist. IMHO, you have just shot yourself in the foot with "In other words the point/purpose of the cast changes depending on what it's used for" I think that D's philosophy is to be clear and simple where possible, having situations where the behaviour of cast changes would be against that philosophy. Also, what happens in the situation where: int foo(int i) {}; <--- I really want this one called char foo (int i) {}; char c = cast(char)(cast(int)foo(10)); Ugly, no? Brad
Feb 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 10:41:05 +1300, <brad domain.invalid> wrote:
  If the compiler errors because it cannot pick the overload, then, by   
 adding a cast I am selecting an overload, the fact that it  
 casts/converts  is the side effect. In other words the point/purpose of  
 the cast changes  depending on what it's used for.

I haven't read the whole thread, but I think I get the general gist. IMHO, you have just shot yourself in the foot with "In other words the point/purpose of the cast changes depending on what it's used for" I think that D's philosophy is to be clear and simple where possible, having situations where the behaviour of cast changes would be against that philosophy.

No, you missunderstand. The behaviour isn't changing at all. Cast still does what cast does, the intent of the programmer is what changes.
 Also, what happens in the situation where:
 int foo(int i) {};	<--- I really want this one called
 char foo (int i) {};

 char c = cast(char)(cast(int)foo(10));

 Ugly, no?

Perhaps, matter of opinion. Your example seems engineered to look bad however. Why do you have a "char foo" function, yet want to use the "int foo" one, to get a char? It makes little or no sense to me. Regan
Feb 22 2005
parent reply brad domain.invalid writes:
Regan Heath wrote:

 
 No, you missunderstand. The behaviour isn't changing at all. Cast still  
 does what cast does, the intent of the programmer is what changes.

are suggesting would make cast select a different function based on the return type. Surely that changes the role of cast? Instead of simply being a type conversion mechanism, it is now a mechanism for resolving ambiguity.
 
 Also, what happens in the situation where:
 int foo(int i) {};    <--- I really want this one called
 char foo (int i) {};

 char c = cast(char)(cast(int)foo(10));

 Ugly, no?

Perhaps, matter of opinion. Your example seems engineered to look bad however. Why do you have a "char foo" function, yet want to use the "int foo" one, to get a char? It makes little or no sense to me. Regan

the real world. Brad
Feb 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 11:51:22 +1300, <brad domain.invalid> wrote:
 Regan Heath wrote:

  No, you missunderstand. The behaviour isn't changing at all. Cast  
 still  does what cast does, the intent of the programmer is what  
 changes.

are suggesting would make cast select a different function based on the return type. Surely that changes the role of cast?

Nope. It's comparable to casting a parameter. eg. void foo(int a) {} void foo(float a) {} foo(cast(int)5); cast still converts the type, which is it's role/function, but, the intent (of the programmer) here is to select the overload and resolve the ambiguity. The only difference is the order in which things happen, I suspect people (you?) think the thing that happens first must be the intent, I disagree.
 Instead of simply being a type conversion mechanism, it is now a  
 mechanism for resolving ambiguity.

It already is, that's part of my point, it's already used to resolve ambiguity, see the above example.
 Also, what happens in the situation where:
 int foo(int i) {};    <--- I really want this one called
 char foo (int i) {};

 char c = cast(char)(cast(int)foo(10));

 Ugly, no?

Your example seems engineered to look bad however. Why do you have a "char foo" function, yet want to use the "int foo" one, to get a char? It makes little or no sense to me. Regan

the real world.

True. I'd argue that if it did you have a bigger 'design' problem. Regan
Feb 22 2005
next sibling parent reply brad domain.invalid writes:
Regan Heath wrote:

 on the  return type.  Surely that changes the role of cast?

Nope. It's comparable to casting a parameter. eg. void foo(int a) {} void foo(float a) {} foo(cast(int)5); cast still converts the type, which is it's role/function, but, the intent (of the programmer) here is to select the overload and resolve the ambiguity.

for selecting a particular overload. I usually use it when assigning a variable that is not quite of the right type. I think that overloading on return type just smells wrong. I get the feeling that it would lead to murky areas, and much of what D is all about getting rid of the murk. For example int foo (int i) {} uint foo (int i) {} char c = foo(3); // which foo, and how are the implicit cast rules defined for different architectures? foo(3); // which foo? Is there a blindingly obvious example of why we might like to have return type overloading? I can't think of a language that has it - but I am willing to learn :)
 It is engineered, yes - but that doesn't mean that it couldn't happen 
 in  the real world.

True. I'd argue that if it did you have a bigger 'design' problem.

The problem is, in the real world with maintenance on a deadline you don't always get to redesign the project, and often what can be done quick and dirty gets done. Brad
Feb 22 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 14:06:05 +1300, <brad domain.invalid> wrote:
 Regan Heath wrote:

 on the  return type.  Surely that changes the role of cast?

void foo(int a) {} void foo(float a) {} foo(cast(int)5); cast still converts the type, which is it's role/function, but, the intent (of the programmer) here is to select the overload and resolve the ambiguity.

for selecting a particular overload. I usually use it when assigning a variable that is not quite of the right type.

Each to thier own.
 I think that overloading on return type just smells wrong.  I get the  
 feeling that it would lead to murky areas, and much of what D is all  
 about getting rid of the murk.  For example

 int foo (int i) {}
 uint foo (int i) {}

 char c = foo(3); // which foo

Neither, D would give an error, same as it does for. void foo(int i); void foo(uint i); char c = 3; foo(c);
 , and how are the implicit cast rules defined for different  
 architectures?

No implicit cast rules. All explicit, as required.
 foo(3); // which foo?

 Is there a blindingly obvious example of why we might like to have  
 return type overloading?  I can't think of a language that has it - but  
 I am willing to learn :)

C++ has it, with a hack, with it's cast operator. The problem with the C++ one, according to Walter is it's implicit nature, meaning it can cause hidden bugs. I agree, which is why I think it should be explicit. For a few examples see my other post to "Georg Wrede" in another branch of this thread.
 It is engineered, yes - but that doesn't mean that it couldn't happen  
 in  the real world.


The problem is, in the real world with maintenance on a deadline you don't always get to redesign the project, and often what can be done quick and dirty gets done.

I know. I believe this behaviour cause more problems than it solves. But that's my personal philosophy. Regan
Feb 22 2005
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Regan Heath wrote:
 On Wed, 23 Feb 2005 11:51:22 +1300, <brad domain.invalid> wrote:
 
 Regan Heath wrote:

  No, you missunderstand. The behaviour isn't changing at all. Cast  
 still  does what cast does, the intent of the programmer is what  
 changes.

cast currently takes one type an converts it to another type. What you are suggesting would make cast select a different function based on the return type. Surely that changes the role of cast?

Nope. It's comparable to casting a parameter. eg.

I would argue that what is being casted is the functions return value (since that's what you are using to chose between the routines). Personally, in that context I prefer to append :type to the function name. (Logically it should be to the parenthesized parameter list, but that gets ugly and unreadable very quickly.) Thus one would have: mysqrt:int(arg); rather than: mysqrt(arg):int; The second form is more elegant in simple cases, but the first version is more readable when the expressions get complex. In fact, one could even have: real x; x = mysqrt:int(arg); which would run the integer version of mysqrt before converting it into a real. I feel that this would be a worthy addition to D, but I don't think it's crucially important. Nice, but not necessary. And not fundamental in the way that the earlier thread about vector operations was.
Feb 23 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 17:03:41 -0800, Charles Hixson  
<charleshixsn earthlink.net> wrote:
 Regan Heath wrote:
 On Wed, 23 Feb 2005 11:51:22 +1300, <brad domain.invalid> wrote:

 Regan Heath wrote:

  No, you missunderstand. The behaviour isn't changing at all. Cast   
 still  does what cast does, the intent of the programmer is what   
 changes.

cast currently takes one type an converts it to another type. What you are suggesting would make cast select a different function based on the return type. Surely that changes the role of cast?


I would argue that what is being casted is the functions return value (since that's what you are using to chose between the routines).

Well, yes, currently that's exactly what is happening. Imagine... void foo(long a){} void foo(float a){} void main() { foo(5); } The compiler gives the error: ex4.d(5): function ex4.foo overloads void(long a) and void(float a) both match argument list for foo And to solve it, you go: foo(cast(int)5); or foo(cast(float)5); depending on what one you want, or alternately you realise there is a bug and fix it in another way. The above is the commonly accepted method of resolving an overload conflict, in D (and other languages) I think it's a natural extension that if you had: long foo(int a){} float foo(int a){} void main() { int a; a = foo(5); } and the compiler gave the error: ex4.d(5): function ex4.foo overloads long(int a) and float(int a) both match return type for foo the programmers response, if they have encountered the first example above, would be to use cast again eg. a = cast(long)foo(5); a = cast(float)foo(5);
 Personally, in that context I prefer to append :type to the function  
 name.  (Logically it should be to the parenthesized parameter list, but  
 that gets ugly and unreadable very quickly.)   Thus one would have:
    mysqrt:int(arg);
 rather than:
    mysqrt(arg):int;

 The second form is more elegant in simple cases, but the first version  
 is more readable when the expressions get complex.  In fact, one could  
 even have:
    real x;
    x = mysqrt:int(arg);
 which would run the integer version of mysqrt before converting it into  
 a real.

They both work, I just prefer cast(type).
 I feel that this would be a worthy addition to D, but I don't think it's  
 crucially important. Nice, but not necessary.

I agree, but I like to discuss the options.
 And not fundamental in the way that the earlier thread about vector  
 operations was.

Each to thier own, I have no use for vector operations myself. Regan
Feb 23 2005
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Regan Heath wrote:
 On Wed, 23 Feb 2005 17:03:41 -0800, Charles Hixson  
 <charleshixsn earthlink.net> wrote:
 
 Regan Heath wrote:

 On Wed, 23 Feb 2005 11:51:22 +1300, <brad domain.invalid> wrote:

 Regan Heath wrote:

  No, you missunderstand. The behaviour isn't changing at all. 
 Cast   still  does what cast does, the intent of the programmer is 
 what   changes.

cast currently takes one type an converts it to another type. What you are suggesting would make cast select a different function based on the return type. Surely that changes the role of cast?

Nope. It's comparable to casting a parameter. eg.

I would argue that what is being casted is the functions return value (since that's what you are using to chose between the routines).

Well, yes, currently that's exactly what is happening. Imagine... void foo(long a){} void foo(float a){} void main() { foo(5); } The compiler gives the error: ex4.d(5): function ex4.foo overloads void(long a) and void(float a) both match argument list for foo And to solve it, you go: foo(cast(int)5); or foo(cast(float)5); depending on what one you want, or alternately you realise there is a bug and fix it in another way. The above is the commonly accepted method of resolving an overload conflict, in D (and other languages) I think it's a natural extension that if you had: long foo(int a){} float foo(int a){} void main() { int a; a = foo(5); } and the compiler gave the error: ex4.d(5): function ex4.foo overloads long(int a) and float(int a) both match return type for foo the programmers response, if they have encountered the first example above, would be to use cast again eg. a = cast(long)foo(5); a = cast(float)foo(5);
 Personally, in that context I prefer to append :type to the function  
 name.  (Logically it should be to the parenthesized parameter list, 
 but  that gets ugly and unreadable very quickly.)   Thus one would have:
    mysqrt:int(arg);
 rather than:
    mysqrt(arg):int;

 The second form is more elegant in simple cases, but the first 
 version  is more readable when the expressions get complex.  In fact, 
 one could  even have:
    real x;
    x = mysqrt:int(arg);
 which would run the integer version of mysqrt before converting it 
 into  a real.

They both work, I just prefer cast(type).
 I feel that this would be a worthy addition to D, but I don't think 
 it's  crucially important. Nice, but not necessary.

I agree, but I like to discuss the options.
 And not fundamental in the way that the earlier thread about vector  
 operations was.

Each to thier own, I have no use for vector operations myself. Regan

selection. The type of the return value is being used to select the method used to do the calculation. A pure decomposition would look sort of like: foo(int, real) returns float::foo(i, x) but that is intensely laborous, and overwhelmingly verbose. And normally one can tell the types of the arguments (though one might argue this about literal strings...char[]? dchar[]? wchar[]?)). Usually one can also determine the return type, but not always. So to be really safe one would specify the type separately from the arguments/return values. But this isn't usually needed. Anyway one can cast the arguments into the appropriate type is that isn't obvious. This, however, disguises that what is significant here is the SELECTION of the routine version. The casting is a way of accomplishing this. For a returned value from a function, I would argue that one might well want to specify it separate from the way that one needed to cast the result. The only obvious example that occurs to me has to do with polar vs. cartesian coordinates, and it's not critical. Still, I would consider being able to select the version of a routine by specifying the type of returned argument (NOT a cast, and hence confusing if specified as if it were one). Because of this I prefer a separate syntax, and my proposed function name decorator subscript seems to me quite reasonable, though an argument could easily be made for many other forms (e.g., a function name decorator prescript: int:foo(x) rather than foo:int(x) ). And again, though I would find this a nice feature, it's acutal need would only be occasional. But with the current system one does wonder how: x = cast(int)cast(real)foo(x); would be interpreted. Still, one can suppose that another layer of parenthesis would clarify things: x = cast(int)(cast(real)foo(x));
Feb 25 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Charles Hixson wrote:
 Regan Heath wrote:
 
 On Wed, 23 Feb 2005 17:03:41 -0800, Charles Hixson  
 <charleshixsn earthlink.net> wrote:

 Regan Heath wrote:

 On Wed, 23 Feb 2005 11:51:22 +1300, <brad domain.invalid> wrote:

 Regan Heath wrote:





 Still, I would consider being able to select the version of a routine by 
 specifying the type of returned argument (NOT a cast, and hence 
 confusing if specified as if it were one).
 
 Because of this I prefer a separate syntax, and my proposed function 
 name decorator subscript seems to me quite reasonable, though an 
 argument could easily be made for many other forms (e.g., a function 
 name decorator prescript:  int:foo(x) rather than foo:int(x) ).
 
 And again, though I would find this a nice feature, it's acutal need 
 would only be occasional.  But with the current system one does wonder how:
 x = cast(int)cast(real)foo(x);
 would be interpreted.  Still, one can suppose that another layer of 
 parenthesis would clarify things:
 x = cast(int)(cast(real)foo(x));

int:foo(x) looks indeed nicer than foo:int(x). My worry is that both notations "pollute the grammar space". (That is, having either of these notations, may later lead to unability to express some more general and useful new thing in the language.) So, my vote (remember, though, that I'm still not for or against this concept per se) would be, either just use cast for this too or create a new word (retsel, prefer, fncast, castfn, ...) for the purpose. (The syntax being the same as for cast!) Syntax would stay the same, semantics of cast itself would not be altered, (if that really is that important), and it is only about one single word more.
Feb 26 2005
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 25 Feb 2005 14:03:40 -0800, Charles Hixson  
<charleshixsn earthlink.net> wrote:
 Still, I would consider being able to select the version of a routine by  
 specifying the type of returned argument (NOT a cast, and hence  
 confusing if specified as if it were one).

This is a good point. One way to look at: cast(int)foo(); is "call foo, and give me an 'int' result". This can be achieved by calling the version of foo that returns an int (if it exists) or calling the version of foo that returns an x, then casting that to an int. Either way, you get the result you want, unless.. there are multiple versions of a function called "foo", doing _different_ things, which if you ask me, is a problem with function naming and/or design. This new way of looking at it, might be the D way, instead of the C/C++ way. Just a thought. I understand other people might not look at it this way.
 Because of this I prefer a separate syntax, and my proposed function  
 name decorator subscript seems to me quite reasonable, though an  
 argument could easily be made for many other forms (e.g., a function  
 name decorator prescript:  int:foo(x) rather than foo:int(x) ).

If I had to choose between the above, I'd pick int:foo(x) but, it does look a bit like a c++ calling syntax, doesn't it?
 And again, though I would find this a nice feature, it's acutal need  
 would only be occasional.  But with the current system one does wonder  
 how:
 x = cast(int)cast(real)foo(x);
 would be interpreted.

Currently, it would cast the return of foo to a real, then an int. If my idea of cast(type)func was implemented then either: - it would be an error requiring parenthesis (not sure) - it would call the function returning 'real' then cast the result to 'int'
 Still, one can suppose that another layer of parenthesis would clarify  
 things:
 x = cast(int)(cast(real)foo(x));

I'm not sure what the current system thinks of this, for my idea I don't think it's "required" but some programmers might find it easier on the eyes, perhaps. Regan
Feb 27 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Xsss Zffff wrote:
 Yiii Wrrrr wrote:
 

still does what cast does, the intent of the programmer is what changes. ..... cast currently takes one type an converts it to another type. What you are suggesting would make cast select a different function based on the return type. Surely that changes the role of cast? <These, and a few tens of other posts -- averaging four to five times the length, per post, of some of the most heavy-weight posts here.> Please, guys. Please! You are bright, talented, and smart. But we all know that already, even if you don't behave like elks on a snowy field in March. Attackin every comma and splitting every hair in the other guy's post is not getting us forward. And, like everyone else here, I presume you have the future of D as the main objective, right. Not showing the rest of us who's got the last word.
Feb 23 2005
prev sibling parent reply xs0 <xs0 xs0.com> writes:
 And I can't produce a compilable example, because the example 
 included  an overload on return type, which is not possible...

No, your example didn't show one, you described one being added later. All I want is an example that compiles. Which should be possible.

Bah, my example was obviously both parts of it. Furthermore, I don't see what you could possibly gain by compiling the first part, as the code was trivial. I also already wrote what will make it compile (cast(int) instead of floor()). Finally, it's not possible, because both parts of the example were from the parallel universe in which return overloads in D exist. I'm assuming you don't have access to the compiler from that universe? :)
 No.
 
 If the compiler errors because it cannot pick the overload, then, by  
 adding a cast I am selecting an overload, the fact that it 
 casts/converts  is the side effect. In other words the point/purpose of 
 the cast changes  depending on what it's used for.

The compiler doesn't error because it cannot pick the overload, it errors, because Walter said it should, and for good reasons. There's a large difference there. As for the purpose, if you say the purpose of casting can be overload selection, then you'll also have to admit that there are also a large number of other possible purposes to casting. But then, you can't argue that it is the best syntax for doing so, because all those other purposes are just as valid, and casting is not somehow the natural choice. And it's certainly not the only choice..
 I think that, because the cast comes first, you're assuming it's the  
 purpose, because the overload selection comes second it's a side effect. 
 A  side effect can occur first, just as the purpose can occur second.

No, I think that because cast by itself has the functionality it has, its purpose is to change/convert types. The fact that that functionality can help you resolve overloads is definitely the side-effect; if there were no overloads, cast's purpose in the language would still remain the same.
 Yes, you can cast a return type now, now the purpose is to cast. Were 
 it  possible to cast to select an overload, then doing so would be the 
 purpose.

cast is not selecting an overload. The coder is the one selecting the overload by changing the type of arguments. If the coder uses the cast operator, it is just his choice, he could use other techniques (for example, instead of casting int to double you can also add 0.0 to it with the same result).
 The purpose of cast now, is not always to convert, but sometimes to 
 select  an overload, the purpose changes depending on where it's used 
 and why (by  definition).

That's just ridiculous. "Cast by definition" has a well-defined purpose and it is not selecting overloads.
 Since you were so smart about compilable examples, I'm surprised you  
 wrote an example that can't be compiled :P (Sorry, couldn't resist)

I find your comment petty.

Well, I find it petty that you proclaimed my example invalid just because you failed to see what its point was and wanted to compile it. At least I apologized..
 The example above cannot be compiled because it is an error, I was 
 giving  an example of an error case which your syntax would solve.
 The same is not true of your example, which was an example of 'before'
 the  collision was added.

Ahh, so you wanted to show something without it actually being compilable code. So did I, yet you keep being a smart-ass about it..
 I am not the only one, see Georg's reply.

I'm also not the only one, see Brad's reply. Now it's 2 vs 2. Let's see who wins. Man, this is fun :) (if you failed to notice, I'm trying to be sarcastic)
 I understand everything you've said above, and I agree it works as 
 you've  said.
 
 But, the point you're missing is that the 'intent' of a statement is 
 not  necessarily the same as the effect generated by the compiler.

The 'intent' of statements has nothing to do with the language (even more so outside computers). And even so, if I see int result=cast(int)func(...); I interpret the so-called intent as "call func(); because it doesn't return int, cast the return value to int". I'll also bet that that would be the interpretation of the vast majority of programmers. Start a poll or something, if you don't believe me.
 This behaviour/method is generally accepted and understood by 
 programmers,  and extending it to include return values will be the 
 same, generally  accepted and understood.

Well, I'd say that if someone understands cast as mainly being the thing to select overloads, he's a newbie (no offense meant to newbies; I was once a newbie too and also believed many wrong things).
 Further it requires no additional syntax and is easily parsable.

Why would no additional syntax for new functionality be a plus? And why would it be more easily parsable than any other syntax? If anything, it's harder - you need to figure out whether there is a function call involved, and if so, if it has overloaded return types and choose some completely different functionality based on the answers to those questions.
 no, it isn't secondary, just the opposite (and casting int to long is  
 converting, the first is 32 bits, the other is 64 bits).

It's not converting per-se, more extending and setting bits to 0.

Whatever.
 int -> uint makes no changes to the memory.

And the point is? That only the memory contents matter? What a weak argument. It's just electric charges in some silicon wafer without interpretation, so think about it a little (to start you of, the same memory bit pattern can be an int, a float, a single UTF32 character, 1-4 UTF8 characters, a processor op, a Java bytecode, and a gazillion other things). To make my own point clear - changing interpretation is far more important than changing memory contents.
 cast(T: int)    { return Something!(T).convert(this); }
 cast(T: double) { return Something!(T).convert(this); }

That syntax does not seem obvious to me.

Why not?

Well.. it looks like a function, returning nothing, taking something called T which must be an int, if that's the case why not just go: cast(int) { .. } in which case it looks just like the c++ hack to me.

well, to me it looks very similar to "template cast(T: int)" (which would mean "a specialization of cast for the type int"). It doesn't take T which must be an int, T is a type. I did consider cast(int) {..}, but that looks like you're trying to cast the code block, so I decided to propose something closer to templates. It doesn't have a return type, because it's already obvious what it is and you'd only have to type it twice.
 So in short your example seems to be the c++ hack, with extra 
 characters  making it less clear (to me).

 How would you suggest overloading opCast() if return-type overloading 
 is  not allowed

No idea, I'll think about this, if, return type overloading is officially "not going to happen, ever".

Well, my guess is that there's like 30% chance of overloading opcast in some completely new way (i.e. with some new syntax) and like 0.0001% chance of overloading return types, so you might as well start thinking about it.
 Ahh, then we're talking at cross puposes.

I clearly stated that I don't think overloading return types is a good idea, with the exception of opCast(). So why the ahh?
 I was just trying to show how T may not always be dummy)?

I dont think it's any different to using a dummy, and using typeof(param) on it.

Again, it's not a parameter, it's a Type.
 It appears Georg agrees with me.

Well, both my wife and my cousin agree with me, so what? For all I know it's just you with different newsreader settings.. Like I said, start a poll and we'll see how cast is understood.. xs0
Feb 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 01:46:42 +0100, xs0 <xs0 xs0.com> wrote:
 And I can't produce a compilable example, because the example  
 included  an overload on return type, which is not possible...

All I want is an example that compiles. Which should be possible.

Bah, my example was obviously both parts of it.

Obviously? I think not.
 Furthermore, I don't see what you could possibly gain by compiling the  
 first part

As I said, I want to fiddle with it.
 , as the code was trivial.

 I also already wrote what will make it compile (cast(int)

Can you post it then, so I can fiddle with it.
 instead of floor()). Finally, it's not possible, because both parts of  
 the example were from the parallel universe in which return overloads in  
 D exist.

I'm interested in the code, before these overloads are used.
 I'm assuming you don't have access to the compiler from that universe? :)

Now you're being silly.
 No.
  If the compiler errors because it cannot pick the overload, then, by   
 adding a cast I am selecting an overload, the fact that it  
 casts/converts  is the side effect. In other words the point/purpose of  
 the cast changes  depending on what it's used for.

The compiler doesn't error because it cannot pick the overload

Well, it could pick one at random.
 , it errors, because Walter said it should, and for good reasons.  
 There's a large difference there.

I don't think so, given that the compiler will never and should never pick one at random.
 As for the purpose, if you say the purpose of casting can be overload  
 selection, then you'll also have to admit that there are also a large  
 number of other possible purposes to casting.

Name one.
 But then, you can't argue that it is the best syntax for doing so,  
 because all those other purposes are just as valid, and casting is not  
 somehow the natural choice.

I believe it is. Georg would agree (it seems).
 And it's certainly not the only choice..

No, but as I said, I believe it's the best one.
 I think that, because the cast comes first, you're assuming it's the   
 purpose, because the overload selection comes second it's a side  
 effect. A  side effect can occur first, just as the purpose can occur  
 second.

No, I think that because cast by itself has the functionality it has, its purpose is to change/convert types. The fact that that functionality can help you resolve overloads is definitely the side-effect; if there were no overloads, cast's purpose in the language would still remain the same.

I give up, you're either ignoring my point, or you simply disagree, either way this is pointless.
 Yes, you can cast a return type now, now the purpose is to cast. Were  
 it  possible to cast to select an overload, then doing so would be the  
 purpose.

cast is not selecting an overload. The coder is the one selecting the overload by changing the type of arguments. If the coder uses the cast operator, it is just his choice, he could use other techniques (for example, instead of casting int to double you can also add 0.0 to it with the same result).

As above.
 The purpose of cast now, is not always to convert, but sometimes to  
 select  an overload, the purpose changes depending on where it's used  
 and why (by  definition).

That's just ridiculous. "Cast by definition" has a well-defined purpose and it is not selecting overloads.

As above.
 Since you were so smart about compilable examples, I'm surprised you   
 wrote an example that can't be compiled :P (Sorry, couldn't resist)


Well, I find it petty that you proclaimed my example invalid just because you failed to see what its point was and wanted to compile it. At least I apologized..

I simply asked you to provide one that compiled, and told you why I wanted it.
 The example above cannot be compiled because it is an error, I was  
 giving  an example of an error case which your syntax would solve.

> the collision was added. Ahh, so you wanted to show something without it actually being compilable code. So did I, yet you keep being a smart-ass about it..

Your code was not representing something that couldn't or shouldn't compile, as I've said it showed the code 'before' adding the fictional feature. My code shouldn't have compiled. If you can't see the difference...
 I am not the only one, see Georg's reply.

I'm also not the only one, see Brad's reply. Now it's 2 vs 2. Let's see who wins. Man, this is fun :) (if you failed to notice, I'm trying to be sarcastic)

I noticed, and am resisting the urge to be sarcastic in return.
 I understand everything you've said above, and I agree it works as  
 you've  said.
  But, the point you're missing is that the 'intent' of a statement is  
 not  necessarily the same as the effect generated by the compiler.

The 'intent' of statements has nothing to do with the language (even more so outside computers). And even so, if I see int result=cast(int)func(...); I interpret the so-called intent as "call func(); because it doesn't return int, cast the return value to int". I'll also bet that that would be the interpretation of the vast majority of programmers. Start a poll or something, if you don't believe me.

Sure, that's the literal meaning, and most people will agree, I do. But, the overall goal is to call a function and for it to result in an int. If cast(int)func causes the function that returns an int to be called then the overall goal has been achieved, just not in the exact manner you have described. As I said, it's the difference between effect and intent.
 This behaviour/method is generally accepted and understood by  
 programmers,  and extending it to include return values will be the  
 same, generally  accepted and understood.

Well, I'd say that if someone understands cast as mainly being the thing to select overloads, he's a newbie (no offense meant to newbies; I was once a newbie too and also believed many wrong things).

I never said "mainly".
 Further it requires no additional syntax and is easily parsable.

Why would no additional syntax for new functionality be a plus?

It depends on each situation, but generally speaking no new syntax means less to learn, less to parse etc.
 And why would it be more easily parsable than any other syntax?

Because it's already being parsed.
 If anything, it's harder - you need to figure out whether there is a  
 function call involved, and if so, if it has overloaded return types and  
 choose some completely different functionality based on the answers to  
 those questions.

That isn't parsing, it's process the results of parsing.
 no, it isn't secondary, just the opposite (and casting int to long is   
 converting, the first is 32 bits, the other is 64 bits).


Whatever.

I see you're no longer interested, so I'll stop now. Regan
Feb 22 2005
parent reply xs0 <xs0 xs0.com> writes:
  No, your example didn't show one, you described one being added 
 later.  All  I want is an example that compiles. Which should be 
 possible.

Bah, my example was obviously both parts of it.

Obviously? I think not.

It starts with "For example, consider:". It ends with "returning the unrounded square root" (plus the parenthesised comment). The next sentence is "The problem is that ...". I feel that it is very obvious that the example was both parts, but you seem to not agree. So be it.
 As I said, I want to fiddle with it.

Go ahead then. Fill what's missing, and fiddle with it. Why would anyone (including me) have to help you fiddle with something? You can hire me, of course, and I'll make you a really nice example to fiddle with. I'll even include several extra functions.
 I'm assuming you don't have access to the compiler from that universe? :)

Now you're being silly.

Yup, but so are you. I stated (in the next sentence; see above) that the example is an example of a problem with return type overloads.
 The compiler doesn't error because it cannot pick the overload

Well, it could pick one at random.
 , it errors, because Walter said it should, and for good reasons.  
 There's a large difference there.

I don't think so, given that the compiler will never and should never pick one at random.

I agree completely :) Now reread what I said..
 As for the purpose, if you say the purpose of casting can be overload  
 selection, then you'll also have to admit that there are also a large  
 number of other possible purposes to casting.

Name one.

Here's three: to round a number (cast(int)3.4) to just keep the lowest eight bits (cast(ubyte)12354) to decrease storage requirements (cast(float)3.4)
 But then, you can't argue that it is the best syntax for doing so,  
 because all those other purposes are just as valid, and casting is 
 not  somehow the natural choice.

I believe it is. Georg would agree (it seems).

Georg also said "Of course, changing the semantics of cast may, for all I know, raise other issues." But you conveniently ignored that.. Brad didn't agree, but you also conveniently ignored that..
 I give up, you're either ignoring my point, or you simply disagree, 
 either  way this is pointless.

Well, you're certainly ignoring a number of my points, so I agree that this is pointless.
 As above.

 That's just ridiculous. "Cast by definition" has a well-defined 
 purpose  and it is not selecting overloads.

As above.

Now, this one still deserves a special attention, so I'll ask explicitly: do you or do you not agree that cast's only _defined_ purpose/functionality in this (or any other) language is that of type conversion?
 I simply asked you to provide one that compiled, and told you why I 
 wanted  it.

Well, like I said, you can hire me and then I can code whatever you want (as long as I'm able to, of course).
 Your code was not representing something that couldn't or shouldn't  
 compile, as I've said it showed the code 'before' adding the fictional  
 feature.

No, it wasn't "before" the fictional feature, it was "after" the fictional feature (I assume you mean overloaded return types). Only the first part was before the second part.
 Well, I'd say that if someone understands cast as mainly being the 
 thing  to select overloads, he's a newbie (no offense meant to 
 newbies; I was  once a newbie too and also believed many wrong things).

I never said "mainly".

No, you didn't use that word. But your argument is that cast is so often used to select overloads, that casting and overload selection are practically the same thing.
 Further it requires no additional syntax and is easily parsable.

Why would no additional syntax for new functionality be a plus?

It depends on each situation, but generally speaking no new syntax means less to learn, less to parse etc.

No, it means more to learn and harder to parse. You could also have all looping statements like this: loop {} (...); // do while statement loop (...) {} // while statement loop (...;...) {} // foreach statement loop (...;...;...) {} // for statement Are you claiming that is easier to learn?
 And why would it be more easily parsable than any other syntax?

Because it's already being parsed.

Not in this way.
 If anything, it's harder - you need to figure out whether there is a  
 function call involved, and if so, if it has overloaded return types 
 and  choose some completely different functionality based on the 
 answers to  those questions.

That isn't parsing, it's process the results of parsing.

Parse: To analyze a sentence or language statement. Parsing breaks down words into functional units that can be converted into machine language. For example, to parse the expression sum salary for title = "MANAGER" the word SUM must be identified as the primary command, FOR as a conditional search, TITLE as a field name and MANAGER as the data to be searched. So, obviously you need to know what that cast() does?
  It's not converting per-se, more extending and setting bits to 0.

Whatever.

I see you're no longer interested, so I'll stop now.

Well, considering how you failed to reply to the last part of my post, I'll assume you had no counter argument and that you agree.. xs0
Feb 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 03:27:44 +0100, xs0 <xs0 xs0.com> wrote:
 As I said, I want to fiddle with it.

Go ahead then. Fill what's missing

I tried, I got to a point where, without knowing what you were trying to show, I couldn't decide what to use, which is why I asked you to do it.
 , and fiddle with it. Why would anyone (including me) have to help you  
 fiddle with something?

You don't 'have' to help. I figured you'd want to, to clarify your example for me. It appears I was wrong.
 The compiler doesn't error because it cannot pick the overload

 , it errors, because Walter said it should, and for good reasons.   
 There's a large difference there.

pick one at random.

I agree completely :) Now reread what I said..

Done. I still don't agree that "there is a large difference there".
 As for the purpose, if you say the purpose of casting can be overload   
 selection, then you'll also have to admit that there are also a large   
 number of other possible purposes to casting.


Here's three: to round a number (cast(int)3.4) to just keep the lowest eight bits (cast(ubyte)12354) to decrease storage requirements (cast(float)3.4)

Excellent. Thanks. I hadn't thought of any of them. So you agree that there is a purpose to casting, other than to simply change the format of the data?
 But then, you can't argue that it is the best syntax for doing so,   
 because all those other purposes are just as valid, and casting is  
 not  somehow the natural choice.


Georg also said "Of course, changing the semantics of cast may, for all I know, raise other issues." But you conveniently ignored that..

I'm trying to think of any and waiting for someone else to think of some.
 Brad didn't agree, but you also conveniently ignored that..

I am conversing with brad as we speak. How am I ignoring him?
 I give up, you're either ignoring my point, or you simply disagree,  
 either  way this is pointless.

Well, you're certainly ignoring a number of my points, so I agree that this is pointless.

I am disagreeing with several of your points.
 As above.

 That's just ridiculous. "Cast by definition" has a well-defined  
 purpose  and it is not selecting overloads.


Now, this one still deserves a special attention, so I'll ask explicitly: do you or do you not agree that cast's only _defined_ purpose/functionality in this (or any other) language is that of type conversion?

Only purpose, disagree. It has several purposes, you've supplied some above. It's functionality, or effect.. agree. It does type conversion.
 I simply asked you to provide one that compiled, and told you why I  
 wanted  it.

Well, like I said, you can hire me and then I can code whatever you want (as long as I'm able to, of course).

So, you have no desire to provide an example to back up your statement, fine.
 Your code was not representing something that couldn't or shouldn't   
 compile, as I've said it showed the code 'before' adding the fictional   
 feature.

No, it wasn't "before" the fictional feature, it was "after" the fictional feature (I assume you mean overloaded return types). Only the first part was before the second part.

Just so we're talking about the same example, it went: int mysqrt(double a) { return floor(sqrt(a)); } double eval_some_cost(...) { double cost=sqrt(..); if (something) cost*=1.3; return cost; } where is the overloaded return type? where is the cast(type) or other syntax of this feature? What I am asking for is the above example to compile, either working, or showing the collision error similar to passing parameters. You also talk about adding another function, I'd like to see that function also, and explore how it can best be: 1. detected 2. solved.
 Well, I'd say that if someone understands cast as mainly being the  
 thing  to select overloads, he's a newbie (no offense meant to  
 newbies; I was  once a newbie too and also believed many wrong things).


No, you didn't use that word. But your argument is that cast is so often used to select overloads, that casting and overload selection are practically the same thing.

No, that was not my argument. I never said "often".
 Further it requires no additional syntax and is easily parsable.

Why would no additional syntax for new functionality be a plus?

means less to learn, less to parse etc.

No, it means more to learn and harder to parse.

Assuming you learn that to resolve an overload collision for parameters requires a cast, it's natural to apply the same learning to overload collision for return type. The parsing is identical, as the syntax is identical. The additional effort/code is in the name resoultion system.
 You could also have all looping statements like this:

 loop {} (...); // do while statement
 loop (...) {} // while statement
 loop (...;...) {} // foreach statement
 loop (...;...;...) {} // for statement

 Are you claiming that is easier to learn?

No.
 And why would it be more easily parsable than any other syntax?


Not in this way.

I think we have a different definition of "parse". To me, parse means take the text and break it into tokens.
 If anything, it's harder - you need to figure out whether there is a   
 function call involved, and if so, if it has overloaded return types  
 and  choose some completely different functionality based on the  
 answers to  those questions.


Parse: To analyze a sentence or language statement. Parsing breaks down words into functional units that can be converted into machine language. For example, to parse the expression sum salary for title = "MANAGER" the word SUM must be identified as the primary command, FOR as a conditional search, TITLE as a field name and MANAGER as the data to be searched.

Yep, that's my definition
 So, obviously you need to know what that cast() does?

No, you just need to identify it as a cast. Parsing "breaks down words into functional units", the phase that does the "converted into machine language" comes after the parsing.
  It's not converting per-se, more extending and setting bits to 0.

Whatever.


Well, considering how you failed to reply to the last part of my post, I'll assume you had no counter argument and that you agree..

You could, that would be illogical. Regan
Feb 22 2005
parent reply xs0 <xs0 xs0.com> writes:
The depth of this thread is becoming rediculous. Maybe we should take 
this to e-mail?

 I tried, I got to a point where, without knowing what you were trying 
 to  show, I couldn't decide what to use, which is why I asked you to do it.

int a() { return 1; } double a() { return 1.5; } // this is the second part double b() { double tmp=a(); return a*2; } happy? :)
 Done. I still don't agree that "there is a large difference there".

There is. You said the compiler errors because it cannot pick an overload. I said that the compiler errors because it doesn't want to pick an overload.
 As for the purpose, if you say the purpose of casting can be 
 overload   selection, then you'll also have to admit that there are 
 also a large   number of other possible purposes to casting.

Name one.

Here's three: to round a number (cast(int)3.4) to just keep the lowest eight bits (cast(ubyte)12354) to decrease storage requirements (cast(float)3.4)

Excellent. Thanks. I hadn't thought of any of them. So you agree that there is a purpose to casting, other than to simply change the format of the data?

No, I don't agree those are purposes, those are side-effects. I said YOU'll have to agree that there are many purposes with reference to the next statement:
 But then, you can't argue that it is the best syntax for doing so,   
 because all those other purposes are just as valid, and casting is  
 not  somehow the natural choice.




 I'm trying to think of any and waiting for someone else to think of some.

Of course, whatever I write is not an issue, because you said so.
 Brad didn't agree, but you also conveniently ignored that..

I am conversing with brad as we speak. How am I ignoring him?

Well, in your summary of the current score, you only mentioned Georg but not Brad. And I never said you ignored Brad.
 Only purpose, disagree. It has several purposes, you've supplied some  
 above. It's functionality, or effect.. agree. It does type conversion.

You skipped DEFINED purpose, even though I emphasized it.
 Just so we're talking about the same example, it went:
 [snip]
 
 where is the overloaded return type?
 where is the cast(type) or other syntax of this feature?

The overloaded return type is in the statement following this code. And it was in reply to what Derek wrote:
 The main [issue] seems to be, what would happen if someone coded a function
 call but did not assign the return to anything? How would the compiler know
 which signature to use if it had to use return-type as a determinate? 

So I don't see what it has to do with cast or other syntax of this feature.
 No, that was not my argument. I never said "often".

Yeah, really funny. So, what exactly is your argument that makes cast() the best possible syntax for selecting an overloaded return type?
 No, it means more to learn and harder to parse.

Assuming you learn that to resolve an overload collision for parameters requires a cast, it's natural to apply the same learning to overload collision for return type.

Resolving an overload collision doesn't require a cast, it's just one way of doing it. Casting the result when there isn't an overload is natural, because casting works the same everywhere. What isn't natural is using cast syntax for something completely different.
 You could also have all looping statements like this:

 loop {} (...); // do while statement
 loop (...) {} // while statement
 loop (...;...) {} // foreach statement
 loop (...;...;...) {} // for statement

 Are you claiming that is easier to learn?

No.

So having the same keyword for looping constructs is not easier to learn, but having the same keyword for both casting types and selection of return-overloaded functions is easier to learn?
 I think we have a different definition of "parse".
 To me, parse means take the text and break it into tokens.

Nope, that's lexing (or lexical analysis, if you want to look it up).
 Parse: To analyze a sentence or language statement. Parsing breaks 
 down  words into functional units that can be converted into machine 
 language.  For example, to parse the expression sum salary for title = 
 "MANAGER"  the word SUM must be identified as the primary command, FOR 
 as a  conditional search, TITLE as a field name and MANAGER as the 
 data to be  searched.

Yep, that's my definition

No, it isn't. It says "Parsing breaks down words into functional units", what you're saying is "Parsing breaks input into words". Also notice how SUM is already identified as a command at this stage, even before machine language is produced.
 Whatever.

I see you're no longer interested, so I'll stop now.

Well, considering how you failed to reply to the last part of my post, I'll assume you had no counter argument and that you agree..

You could, that would be illogical.

It's also illogical to claim I was no longer interested (considering the amount of text after "Whatever"), but you still did.. xs0
Feb 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 04:58:15 +0100, xs0 <xs0 xs0.com> wrote:
 The depth of this thread is becoming rediculous. Maybe we should take  
 this to e-mail?

 I tried, I got to a point where, without knowing what you were trying  
 to  show, I couldn't decide what to use, which is why I asked you to do  
 it.

int a() { return 1; } double a() { return 1.5; } // this is the second part double b() { double tmp=a(); return a*2; } happy? :)

Yes, thank you. Small modification: int a() { return 1; } double a() { return 1.5; } // this is the second part double c() { double tmp=a(); return tmp*2; } void main() { printf("%f\n",c()); } ok? The compiler gives: ex3.d(2): function ex3.a conflicts with ex3.a at ex3.d(1) (the file was called ex3.d) Weren't you arguing this would happen silently, and cause a bug? I expected/hoped it to complain, as it does. As long as it does error, then the programmer is forced to consider the problem, and add a solution. Following my example below, I believe the programmer would attempt to use cast().
 Done. I still don't agree that "there is a large difference there".

There is. You said the compiler errors because it cannot pick an overload. I said that the compiler errors because it doesn't want to pick an overload.

I agree, however, given that there is a approaching 0 chance of a compiler wanting to pick one based on no information, i.e. random, they're functionally equivalent, right? Regardless, this is a side-argument, and not relevant to the main argument, so lets just agree to disagree, ok?
 As for the purpose, if you say the purpose of casting can be  
 overload   selection, then you'll also have to admit that there are  
 also a large   number of other possible purposes to casting.

Name one.

Here's three: to round a number (cast(int)3.4) to just keep the lowest eight bits (cast(ubyte)12354) to decrease storage requirements (cast(float)3.4)

that there is a purpose to casting, other than to simply change the format of the data?

No, I don't agree those are purposes, those are side-effects. I said YOU'll have to agree that there are many purposes with reference to the next statement:
 But then, you can't argue that it is the best syntax for doing so,    
 because all those other purposes are just as valid, and casting is   
 not  somehow the natural choice.




 I'm trying to think of any and waiting for someone else to think of  
 some.

Of course, whatever I write is not an issue, because you said so.

No, I am listening to what you write, and replying, I just disagree, how am I ignroing you?
 Brad didn't agree, but you also conveniently ignored that..


Well, in your summary of the current score, you only mentioned Georg but not Brad. And I never said you ignored Brad.

It wasn't a summary, I was simply responding to your statement that no-one would agree with me, I thought 1 example was enough.
 Only purpose, disagree. It has several purposes, you've supplied some   
 above. It's functionality, or effect.. agree. It does type conversion.

You skipped DEFINED purpose, even though I emphasized it.

I am not saying that cast's main, or defined purpose isn't to convert a variable. Let me re-state my argument, I don't think it was presented in a concise manner... What I'm saying is, that, for example, if you have: void foo(long a){} void foo(float a){} void main() { foo(5); } The compiler gives the error: ex4.d(5): function ex4.foo overloads void(long a) and void(float a) both match argument list for foo And to solve it, you go: foo(cast(int)5); or foo(cast(float)5); depending on what one you want, or alternately you realise there is a bug and fix it in another way. The above is the commonly accepted method of resolving an overload conflict, in D (and other languages) I think it's a natural extension that if you had: long foo(int a){} float foo(int a){} void main() { int a; a = foo(5); } and the compiler gave the error: ex4.d(5): function ex4.foo overloads long(int a) and float(int a) both match return type for foo (this exact error doesn't exist, because it doesn't consider return types, instead we get an error like your example showed above) the programmers natural response, if they have encountered the first example above, would be to use cast again eg. a = cast(long)foo(5); a = cast(float)foo(5);
 Just so we're talking about the same example, it went:
 [snip]
  where is the overloaded return type?
 where is the cast(type) or other syntax of this feature?

The overloaded return type is in the statement following this code. And it was in reply to what Derek wrote:

Right, I just wanted it in code, so I could see exactly what you meant, you've given me that now, I'm happy. :)
 The main [issue] seems to be, what would happen if someone coded a  
 function
 call but did not assign the return to anything? How would the compiler  
 know
 which signature to use if it had to use return-type as a determinate?

So I don't see what it has to do with cast or other syntax of this feature.

Who wrote the above? I'd say if the return-type was indeterminate it would be an error requiring cast(type) to resolve. eg. int foo() {} double foo() {} void main() { foo(); //error }
 No, that was not my argument. I never said "often".

Yeah, really funny. So, what exactly is your argument that makes cast() the best possible syntax for selecting an overloaded return type?

See above. I have restated it for clarity.
 No, it means more to learn and harder to parse.

parameters requires a cast, it's natural to apply the same learning to overload collision for return type.

Resolving an overload collision doesn't require a cast, it's just one way of doing it.

Sure, but it's the commonly accepted way for D.
 Casting the result when there isn't an overload is natural, because  
 casting works the same everywhere.

Sure, I'm not disagreeing here.
 What isn't natural is using cast syntax for something completely  
 different.

My argument is that it's not completely different, see my reasoning above with the example.
 You could also have all looping statements like this:

 loop {} (...); // do while statement
 loop (...) {} // while statement
 loop (...;...) {} // foreach statement
 loop (...;...;...) {} // for statement

 Are you claiming that is easier to learn?


So having the same keyword for looping constructs is not easier to learn, but having the same keyword for both casting types and selection of return-overloaded functions is easier to learn?

The difference between cast and your loop example is that the syntax above changes depending on the purpose, the cast syntax doesn't, basically I don't think it's a fair analogy. Who knows, perhaps having only one keyword would have been easier? It would have made searching for loops easier, regardless, this is another argument entirely.
 I think we have a different definition of "parse".
 To me, parse means take the text and break it into tokens.

Nope, that's lexing (or lexical analysis, if you want to look it up).

It seems the same as the definition below, to me.
 Parse: To analyze a sentence or language statement. Parsing breaks  
 down  words into functional units that can be converted into machine  
 language.  For example, to parse the expression sum salary for title =  
 "MANAGER"  the word SUM must be identified as the primary command, FOR  
 as a  conditional search, TITLE as a field name and MANAGER as the  
 data to be  searched.


No, it isn't. It says "Parsing breaks down words into functional units", what you're saying is "Parsing breaks input into words".

I said "take the text and break it into tokens". text == words. tokens == functional units. as in, it splits the text, gets "cast", "(", "type", ")" and turns "cast" into tokCAST or whatever it uses internally to represent it.
 Also notice how SUM is already identified as a command at this stage,  
 even before machine language is produced.

Sure, just as cast would be, right? As in, it knows it's a cast, but doesn't necessarily know what it has to do about it yet, as that comes later, yes?
 Whatever.

I see you're no longer interested, so I'll stop now.

Well, considering how you failed to reply to the last part of my post, I'll assume you had no counter argument and that you agree..


It's also illogical to claim I was no longer interested (considering the amount of text after "Whatever"), but you still did..

I was simply stating my impression, IMO the argument was degrading into a slagging match, and had drifted off point, I think we've fixed it, above. Regan
Feb 23 2005
parent reply xs0 <xs0 xs0.com> writes:
 Weren't you arguing this would happen silently, and cause a bug?

No.
 I agree, however, given that there is a approaching 0 chance of a 
 compiler  wanting to pick one based on no information, i.e. random, 
 they're  functionally equivalent, right?

No, there could be a large amount of rules to make the process totally deterministic (like in C++), but D's design says screw that, it's an error.
 Regardless, this is a side-argument, and not relevant to the main  
 argument, so lets just agree to disagree, ok?

Sure, whatever you want.
 It wasn't a summary, I was simply responding to your statement that 
 no-one  would agree with me, I thought 1 example was enough.

My statement was actually
 But then, you can't argue that it is the best syntax for doing
 so,  because all those other purposes are just as valid, and
 casting is not  somehow the natural choice.




Where does it say no-one would agree with you?
 Let me re-state my argument, I don't think it was presented in a 
 concise  manner...
 
 What I'm saying is, that, for example, if you have:
 [snip]
 
 And to solve it, you go:
   foo(cast(int)5);
 or
   foo(cast(float)5);
 
 depending on what one you want, or alternately you realise there is a 
 bug  and fix it in another way.
 
 The above is the commonly accepted method of resolving an overload  
 conflict, in D (and other languages)

Well, at least in Java that works just fine (foo(5), that is), and AFAIK in C++ as well, so forcing the user to resolve overload ambiguities is D-only. And I'd certainly resolve it with foo(5L) // or foo(5.0) not with cast()..
 I think it's a natural extension that if you had:
 
 long foo(int a){}
 float foo(int a){}
 void main() {int a=foo(5); }
 
 and the compiler gave the error:
 [snip]
 the programmers natural response, if they have encountered the first  
 example above, would be to use cast again eg.
 
 a = cast(long)foo(5);
 a = cast(float)foo(5);

Except that the second case wouldn't work (and the first one should't as well, because long shouldn't be implicitly castable to int), because when you say cast(float) you get a float, not an int, even if you managed to explain to the compiler which function you wanted to call. So even you made an error because of your syntax, showing that it's not a good syntax for this kind of functionality...
 So I don't see what it has to do with cast or other syntax of this  
 feature.

Who wrote the above?

Why do I need to repeat everything? Derek wrote that.
 I'd say if the return-type was indeterminate it 
 would  be an error requiring cast(type) to resolve. eg.
 
 int foo() {}
 double foo() {}
 
 void main() {
   foo();    //error
 }

This has nothing to do with anything. Go read what was said if you want to comment on it.
 What isn't natural is using cast syntax for something completely  
 different.

My argument is that it's not completely different, see my reasoning above with the example.

But your reasoning is wrong. The reason cast works for overload selection with parameters is because it changes the type of those parameters, that is what cast does and you agreed that that is what cast does. The compiler doesn't see cast(int) and figures out you're trying to call the int function, it sees a parameter of type int and decides there is no ambiguity (i.e. it doesn't care if you cast it or do anything else with it, it just cares about its type). void foo(int a) {} void foo(double a) {} void main() { int a=5; foo(a); } This works, because a is already of type int. Walter was just nice enough to handle constants slightly differently, because 5 is both an int and a double, until you specify what it is in some manner (by assigning it to a typed variable, or casting it, or whatnot). If you ask the compiler to select a function because there is a cast() in front of the call, you're not changing the type of anything and it is completely different.
 The difference between cast and your loop example is that the syntax 
 above  changes depending on the purpose, the cast syntax doesn't, 
 basically I  don't think it's a fair analogy.

I was merely replying to your claim that less syntax is easier to learn.
 Nope, that's lexing (or lexical analysis, if you want to look it up).

It seems the same as the definition below, to me.

Well, everyone else seems to think that there is a difference between lexical analysis and parsing..
 No, it isn't. It says "Parsing breaks down words into functional 
 units",  what you're saying is "Parsing breaks input into words".

I said "take the text and break it into tokens". text == words. tokens == functional units.

no, it's actually like this: input/text: "cast(type)(a+b+c)" | LEXING | V words/tokens = cast, (, "type", ), (, "a", +, "b", +, "c", ) | PARSING | V CAST_EXPR [ type: TYPE [ identifier: "type" ] value:SUM [ left-side: SUM [ left-side: VAR[identifier:"a"] right-side:VAR[identifier:"b"] ] right-side:VAR[identifier:"c"] ] ] (the latter is just one way of expressing what parsing produces, its typically a so-called abstract syntax tree (AST), but I don't have time to draw ASCII diagrams to represent it graphically). This is the first time it knows a cast is involved. It also knows that "type" is supposed to be a type identifier, that a sum will happen, and that variables a, b and c are referenced. What follows is usually semantic analysis, optimization (high-level), compilation, another optimization (on machine code) and linking. You see how "(" is not a functional unit? It's a token, and it even gets discarded in the parsing process, because it's not needed anymore. If you still don't believe me, go to dmd/src/dmd and check lexer.c and parse.c
 As in, it knows it's a cast, but doesn't necessarily know what it has 
 to  do about it yet, as that comes later, yes?

No, after just doing lexing it doesn't know it's a cast. xs0
Feb 23 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 24 Feb 2005 02:20:42 +0100, xs0 <xs0 xs0.com> wrote:
 What isn't natural is using cast syntax for something completely   
 different.

above with the example.

But your reasoning is wrong.

I don't think so, and nothing you have said has convinced me. Sounds like it's time to agree to disagree as they say, we're getting nowhere. Regan
Feb 23 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:
 On Tue, 22 Feb 2005 01:26:44 +0100, xs0 <xs0 xs0.com> wrote:
 
 This whole issue comes down to where you draw the line, where you  
 balance  convenience vs pedanticism. (if that aint a word it should  
 be). Walter has  drawn it in one place, almost everyone disagrees in  
 some way, large or  small.



True. But then we might not always be able to see the real reason. After all, his CV looks better than ours! Also, some of the reasons might take a lot of explaining, especially if they're subtle. All that is time away from actually writing the D compiler. .-) And sometimes it may be just as simple as a feature demanding more research and writing from Walter, than what it's worth.
 I certainly don't disagree with Walter; actually I think D is the 
 best  language I've ever seen (at least in the 
 compiled-to-native-code  category).


Me too! And an ever increasing number of my friends here!
 Well, considering how opCast is the only problem where not having  
 return-type-overloads is really an issue, perhaps it could just get  
 special treatment and the problem'd be solved?


FTR: I still have no opinion for or against overloading on return type. Can we find examples where not having it produces cumbersome code compared with having RTO?
Feb 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Feb 2005 10:23:16 +0200, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Regan Heath wrote:
 On Tue, 22 Feb 2005 01:26:44 +0100, xs0 <xs0 xs0.com> wrote:

 This whole issue comes down to where you draw the line, where you   
 balance  convenience vs pedanticism. (if that aint a word it should   
 be). Walter has  drawn it in one place, almost everyone disagrees in   
 some way, large or  small.



True. But then we might not always be able to see the real reason. After all, his CV looks better than ours!

Well, in most cases I tend to agree with Walter, but, it's not due to his CV.
 Also, some of the reasons
 might take a lot of explaining, especially if they're subtle. All
 that is time away from actually writing the D compiler.   .-)

True, and we don't want that. :0)
 And sometimes it may be just as simple as a feature demanding more
 research and writing from Walter, than what it's worth.

True, which is why it's up to us to attempt to show how useful it can be, then he has some idea whether it's worth looking at.
 I certainly don't disagree with Walter; actually I think D is the  
 best  language I've ever seen (at least in the  
 compiled-to-native-code  category).


Me too! And an ever increasing number of my friends here!

I think most people here, are here for this very reason. Or they think D will become the best and want to follow it's evolution.
 Well, considering how opCast is the only problem where not having   
 return-type-overloads is really an issue, perhaps it could just get   
 special treatment and the problem'd be solved?


FTR: I still have no opinion for or against overloading on return type.

Fair enough.
 Can we find examples where not having it produces cumbersome code
 compared with having RTO?

Lets use opCast as an example. I think writing a class which you want to be convertable to several different basic types is a case where this would be useful, for example... class SomeNewType { int opCast() {} float opCast() {} } void main() { SomeNewType p = new SomeNewType(); int a; float b; a = p; //error cannot implicitly cast from SomeNewType to int b = p; //error cannot implicitly cast from SomeNewType to float a = cast(int)p; //ok b = cast(float)p; //ok } to achieve this, now, you need to use a seperate function for each i.e. class SomeNewType { int toInt() {} float toFloat() {} } Not bad per-se. But, it leaves one wondering what the point of opCast is. Maybe the rationale is that you should only need 1 opCast, as in you cast to x, and all the other types you need should be castable from that type? If so, then why does int cast to more than 1 type? surely these cases are comparable? Lets consider it when writing a template, i.e. generic programming. template foo(T) { void foo(T p) { int a = cast(int)p; //would be possible int a = p.toInt(); //ok } } but lets go further and try... template foo(T, NT) { void foo(T p, out NT q) { q = cast(typeof(NT))p; //would be possible q = p.to???(); //impossible? } } Granted, it seems reasonably rare for most programs to need to do this, there may be workarounds? Another possible use is optimisation, it may be possible for your class to return types x, y and z more efficiently than returning x and having something else convert from x to y or x to z. i.e. maybe you're caching those values. or simply producing them from scratch is faster than converting from an existing value of another type. Overall I think this is a minor feature, and maybe it's more work than it's worth. But then, maybe someone can come up with a really good use for it. I've done my best to lay it all out for everyone as I see it. Regan
Feb 22 2005
parent Derek Parnell <derek psych.ward> writes:
On Wed, 23 Feb 2005 11:36:27 +1300, Regan Heath wrote:

 On Tue, 22 Feb 2005 10:23:16 +0200, Georg Wrede <georg.wrede nospam.org>  
 wrote:
 Regan Heath wrote:
 On Tue, 22 Feb 2005 01:26:44 +0100, xs0 <xs0 xs0.com> wrote:

 This whole issue comes down to where you draw the line, where you   
 balance  convenience vs pedanticism. (if that aint a word it should   
 be). Walter has  drawn it in one place, almost everyone disagrees in   
 some way, large or  small.



True. But then we might not always be able to see the real reason. After all, his CV looks better than ours!

Well, in most cases I tend to agree with Walter, but, it's not due to his CV.
 Also, some of the reasons
 might take a lot of explaining, especially if they're subtle. All
 that is time away from actually writing the D compiler.   .-)

True, and we don't want that. :0)
 And sometimes it may be just as simple as a feature demanding more
 research and writing from Walter, than what it's worth.

True, which is why it's up to us to attempt to show how useful it can be, then he has some idea whether it's worth looking at.
 I certainly don't disagree with Walter; actually I think D is the  
 best  language I've ever seen (at least in the  
 compiled-to-native-code  category).


Me too! And an ever increasing number of my friends here!

I think most people here, are here for this very reason. Or they think D will become the best and want to follow it's evolution.
 Well, considering how opCast is the only problem where not having   
 return-type-overloads is really an issue, perhaps it could just get   
 special treatment and the problem'd be solved?


FTR: I still have no opinion for or against overloading on return type.

Fair enough.
 Can we find examples where not having it produces cumbersome code
 compared with having RTO?

Lets use opCast as an example. I think writing a class which you want to be convertable to several different basic types is a case where this would be useful, for example... class SomeNewType { int opCast() {} float opCast() {} } void main() { SomeNewType p = new SomeNewType(); int a; float b; a = p; //error cannot implicitly cast from SomeNewType to int b = p; //error cannot implicitly cast from SomeNewType to float a = cast(int)p; //ok b = cast(float)p; //ok } to achieve this, now, you need to use a seperate function for each i.e. class SomeNewType { int toInt() {} float toFloat() {} } Not bad per-se. But, it leaves one wondering what the point of opCast is. Maybe the rationale is that you should only need 1 opCast, as in you cast to x, and all the other types you need should be castable from that type? If so, then why does int cast to more than 1 type? surely these cases are comparable? Lets consider it when writing a template, i.e. generic programming. template foo(T) { void foo(T p) { int a = cast(int)p; //would be possible int a = p.toInt(); //ok } } but lets go further and try... template foo(T, NT) { void foo(T p, out NT q) { q = cast(typeof(NT))p; //would be possible q = p.to???(); //impossible? } } Granted, it seems reasonably rare for most programs to need to do this, there may be workarounds? Another possible use is optimisation, it may be possible for your class to return types x, y and z more efficiently than returning x and having something else convert from x to y or x to z. i.e. maybe you're caching those values. or simply producing them from scratch is faster than converting from an existing value of another type. Overall I think this is a minor feature, and maybe it's more work than it's worth. But then, maybe someone can come up with a really good use for it. I've done my best to lay it all out for everyone as I see it. Regan

I could use such a feature today (yesterday actually). -- Derek Melbourne, Australia 23/02/2005 9:39:53 AM
Feb 22 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:
 In other words, implicit conversion causes the problem, and it's a  
 seperate issue to solve, adding this new explicit function selection 
 will  not add new sources of bugs, they're already there.

This reveals a useful use for overloading on return type. One could explicitly disallow certain cases: real foo(sometype z) {whatever} int foo(sometype z) {assert(0)} real x; x = foo(bla); // ok int y; y = foo(bla); // Assertion failed. The overloading mechanism should of course first search the overloads extensively, before any implicit conversions. Actually, we might even decide that for any function that has return type overload, _no implicit conversions are allowed_.
Feb 22 2005
prev sibling parent reply Derek <derek psych.ward> writes:
On Mon, 21 Feb 2005 14:03:04 +0100, xs0 wrote:

 The main one seems to be, what would happen if someone coded a function
 call but did not assign the return to anything? How would the compiler know
 which signature to use if it had to use return-type as a determinate?

Well, that's not the only "main" issue, imho.. For example, consider: int mysqrt(double a) { return floor(sqrt(a)); } double eval_some_cost(...) { double cost=sqrt(..); if (something) cost*=1.3; return cost; } Now, this works fine and all. But, I (or my co-worker) can decide sometime in the future that there should also be a double mysqrt(double) returning the unrounded square root (or even something completely different, but that is bad style, I guess). The problem is that without any change in either the int version or in eval_some_cost(), the code will produce different results. This is most probably the reason why ambiguous function calls are not allowed and you need to be explicit which version you want to use.

I understand what you are saying. However, I imagine it would work in a similar manner to function signature matching does today. That is it would have to exactly match or an error is produced. Consider what it currently does... void foo(real x) {} void main() { foo(5); } This compiles okay as the compiler silently (implictly) converts the integer 5 to a real 5 before calling the foo routine. But, to paraphrase a collegue "But, I (or my co-worker) can decide sometime in the future that there should also be an foo(int)", such as ... void foo(real x) {} void foo(int x) {} void main() { foo(5); } Now the compiler complains because of the ambiguity. So if return type was included in the deal, your example would also have the compiler complaining when the new double mysqrt() was included into the mix.
 
 For example...
    cast(int)foo('x');  // Call the 'int' version and ignore the result.
    bar( cast(real)foo('y') ); // Call the 'real' version of foo and bar.

Hmm, but there's no casting, so why use the cast() operator? I'd like better something along the lines of

Because it was just an example! I'm not seriously saying *this must be the syntax*. But I did note that you understood what I was getting at ;-)
 foo:int('x');
 bar(foo:real('y'));

Maybe ... foo('x'):int; bar( foo('y'):real; ); not that it matters too much (because Walter will *never* implement it anyway - too much against his world-view, I suspect).
 And cast(type)obj can almost be directly translated to obj.opCast:type() 
 (almost because implicit casts should still be allowed when there's no 
 ambiguity). Ambiguity should be defined differently for return types, 
 though - the above problem is still not solved, even if there is an 
 exact match (actually, precisely because of the exact match).

Sorry, but I don't follow you here. What do you mean by "the above problem is still not solved, ..."? If the coder explicitly tells the compiler which version of the function to call, what is the problem?
 So, I'd say that if there are return types A and B, and either can be 
 implicitly casted to the other, the caller should be forced to specify 
 which is the right one when using either.

Yes, exactly.
 That's ok, though; even if you write A a=func(), it actually doesn't 
 mean that func() should return something of type A, it just means that 
 you'd like the compiler to implicitly cast it to A. 

If it is possible, but this is a different thing to getting the compiler to sort out which of the possible function signatures to select. Which is what I'm talking about.
 This logic is 
 actually the same as with double a=2/3 -- you'll still get 0, because 
 the casting gets done on assignment, not evaluation..

True, but what has this got to do with function selection? I'm missing the point I think, sorry. -- Derek Melbourne, Australia
Feb 21 2005
parent xs0 <xs0 xs0.com> writes:
 Now the compiler complains because of the ambiguity. 

It does? That's great, actually. My guess, however, is that it only does so because a constant was used. If it was a variable, it wouldn't (or maybe I'm forgetting something?)
 Maybe ...
    foo('x'):int;
    bar( foo('y'):real; );
 
 not that it matters too much (because Walter will *never* implement it
 anyway - too much against his world-view, I suspect).

Well, I agree it's best not to implement it (see my other post), but to explain my syntax - my first thought was foo.int('x'), which somehow makes sense to me, but there's two problems - int has to be looked up to determine whether it is a type (which is not a problem with basic types, but is with everything else), and furthermore, if you have a type within a type, you can't be sure what is what. is a.b.c "a returning b.c" or "a.b returning c"? so, I just replaced the dot with : to avoid both problems (and, it has a similar meaning as in template(T : Q), which is specialization)
 Sorry, but I don't follow you here. What do you mean by "the above problem
 is still not solved, ..."? If the coder explicitly tells the compiler which
 version of the function to call, what is the problem?

If the coder does that, there is no problem. The "above problem" is that perhaps he didn't at some point in time, because there was nothing to specify (i.e. there was only one method). Later, another method was added, and because the return type exactly matched the inferred return type (_double_ a = mysqrt(..)), another method was chosen and it was the wrong one.
 If it is possible, but this is a different thing to getting the compiler to
 sort out which of the possible function signatures to select. Which is what
 I'm talking about.

Well, you said "To counter this, one could make the rule that every call to a function must either assign the result or [snip]". I think that just assigning the result is not indicative enough..
 [snip: double a=2/3]

point I think, sorry.

The point was that the type you're assigning the result to doesn't have any influence on how that result is produced, which is good - you don't want 2/3 to mean 0 sometimes and 0.66666 other times. The same goes for methods (i.e. you don't want another method to be chosen, just because the result will be assigned to some other type). xs0
Feb 21 2005
prev sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
I still think the signature for opCast should change to something like:
   bit opCast(inout T result);

Return 'true' on success, 'false' on failure (could not cast for some 
reason).  Then we could have as many opCasts as we need.

My apologies if this has come up already.

-- Chris S
Feb 22 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Feb 2005 16:53:50 -0600, Chris Sauls <ibisbasenji gmail.com>  
wrote:
 I still think the signature for opCast should change to something like:
    bit opCast(inout T result);

 Return 'true' on success, 'false' on failure (could not cast for some  
 reason).  Then we could have as many opCasts as we need.

Interesting.. how would you use it? same as other types i.e. cast(Type)object; if so, where/how do you get the return value? I assume the inout gets assigned to the lhs?
 My apologies if this has come up already.

I don't remember it, but I've not been here as long as some, and my memory isn't perfect. Regan
Feb 22 2005
parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Regan Heath wrote:
 if so, where/how do you get the return value?
 I assume the inout gets assigned to the lhs?

You assume right. My thought-train went something like: class Foo { private int value; bit opCast(inout int result) { result = value; return true; } bit opCast(inout float result) { return false; } } int i, j; float f; Foo foo = new Foo; i = cast(int) foo; // foo.opCast(i); j = (cast(int) foo) + 5; // int tmp; foo.opCast(foo); j = tmp + 5; f = cast(float) foo; // throws an exception (opCast returned false) I'm not sure how I feel about the tmp variable, but D already does similar things to implement some other features. Such as the auto-generated function "literal" that Walter recently mentioned foreach loops generate. (If I remember that right.) -- Chris S
Feb 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Feb 2005 17:19:32 -0600, Chris Sauls <ibisbasenji gmail.com>  
wrote:
 Regan Heath wrote:
 if so, where/how do you get the return value?
 I assume the inout gets assigned to the lhs?

You assume right. My thought-train went something like: class Foo { private int value; bit opCast(inout int result) { result = value; return true; } bit opCast(inout float result) { return false; } } int i, j; float f; Foo foo = new Foo; i = cast(int) foo; // foo.opCast(i); j = (cast(int) foo) + 5; // int tmp; foo.opCast(foo); j = tmp + 5;

Typo? did you mean foo.opCast(tmp)?
 f = cast(float) foo;      // throws an exception (opCast returned false)

Ok, so this is different behaviour to when you cast a class to an incorrect base eg. class A {} class B {} B b = new B(); A a; a = cast(A)b; //a == null after this call, no exception thrown. Could it, should it be the same? eg. opCast returns false, set lhs to typeof(lhs).init?
 I'm not sure how I feel about the tmp variable, but D already does  
 similar things to implement some other features.  Such as the  
 auto-generated function "literal" that Walter recently mentioned foreach  
 loops generate.  (If I remember that right.)

Couldn't the tmp be optimised away? Regan
Feb 22 2005
parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Regan Heath wrote:
 i = cast(int) foo;        // foo.opCast(i);
 j = (cast(int) foo) + 5;  // int tmp; foo.opCast(foo); j = tmp + 5;

Typo? did you mean foo.opCast(tmp)?

Woops. I did.
 f = cast(float) foo;      // throws an exception (opCast returned false)

Ok, so this is different behaviour to when you cast a class to an incorrect base eg. class A {} class B {} B b = new B(); A a; a = cast(A)b; //a == null after this call, no exception thrown.

Or you could set the result param to null and return true, to mimic the language-defined cast.
 
 Could it, should it be the same?
 eg. opCast returns false, set lhs to typeof(lhs).init?

I hadn't thought of that...
 Couldn't the tmp be optimised away?

Surely. -- Chris S
Feb 22 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Feb 2005 18:49:43 -0600, Chris Sauls <ibisbasenji gmail.com>  
wrote:
 Regan Heath wrote:
 i = cast(int) foo;        // foo.opCast(i);
 j = (cast(int) foo) + 5;  // int tmp; foo.opCast(foo); j = tmp + 5;


Woops. I did.

I thought so :)
 f = cast(float) foo;      // throws an exception (opCast returned  
 false)

incorrect base eg. class A {} class B {} B b = new B(); A a; a = cast(A)b; //a == null after this call, no exception thrown.

Or you could set the result param to null and return true, to mimic the language-defined cast.

Indeed. So the questions are: - Is it better to throw an exception or not? - If it's better, should the built in casts do it? - Can that be decided in general or should it be decided on a case by case basis?
  Could it, should it be the same?
 eg. opCast returns false, set lhs to typeof(lhs).init?

I hadn't thought of that...

It would mimic the built in cast behaviour.
 Couldn't the tmp be optimised away?

Surely.

In which case I think this idea has merit. Can anyone think of anything 'bad'(tm) about it? Regan
Feb 22 2005
prev sibling parent reply xs0 <xs0 xs0.com> writes:
 I still think the signature for opCast should change to something like:
   bit opCast(inout T result);
 
 Return 'true' on success, 'false' on failure (could not cast for some reason).
 Then we could have as many opCasts as we need. 

Two questions: 1) why inout not just out? 2) why not have void return type, and in case of failure you can just throw an exception yourself? presumably this would be a rare occasion, and you can avoid a bunch of checks this way.. Otherwise, not a bad idea at all, if you ask me. The only issue I can see is that the result is not returned (as in "return something;"), so it can't be used in expressions as easily (i.e. you need those temporary variables, which probably complicates implementation significantly). xs0
Feb 22 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 23 Feb 2005 02:09:08 +0100, xs0 wrote:

 I still think the signature for opCast should change to something like:
   bit opCast(inout T result);
 
 Return 'true' on success, 'false' on failure (could not cast for some reason).
 Then we could have as many opCasts as we need. 

Two questions: 1) why inout not just out? 2) why not have void return type, and in case of failure you can just throw an exception yourself? presumably this would be a rare occasion, and you can avoid a bunch of checks this way.. Otherwise, not a bad idea at all, if you ask me. The only issue I can see is that the result is not returned (as in "return something;"), so it can't be used in expressions as easily (i.e. you need those temporary variables, which probably complicates implementation significantly).

Agree, this is not a bad compromise. void opCast(out T result); Eg. class Foo{ int val; void opCast(out uint result) { if (val < 0) throw new Exception( std.string.format("Foo: Cannot convert %d to a uint", val)); result = cast(uint)val * 100; } } . . . Foo A = new Foo; uint y = A; . . . Hmmm... this I could really use right now! -- Derek Melbourne, Australia 23/02/2005 12:38:22 PM
Feb 22 2005
parent reply Kris <Kris_member pathlink.com> writes:
In article <lx6y84tsdjq9.6hf2uroobfec$.dlg 40tude.net>, Derek Parnell says...
On Wed, 23 Feb 2005 02:09:08 +0100, xs0 wrote:

 I still think the signature for opCast should change to something like:
   bit opCast(inout T result);
 
 Return 'true' on success, 'false' on failure (could not cast for some reason).
 Then we could have as many opCasts as we need. 

Two questions: 1) why inout not just out? 2) why not have void return type, and in case of failure you can just throw an exception yourself? presumably this would be a rare occasion, and you can avoid a bunch of checks this way.. Otherwise, not a bad idea at all, if you ask me. The only issue I can see is that the result is not returned (as in "return something;"), so it can't be used in expressions as easily (i.e. you need those temporary variables, which probably complicates implementation significantly).

Agree, this is not a bad compromise. void opCast(out T result); Eg. class Foo{ int val; void opCast(out uint result) { if (val < 0) throw new Exception( std.string.format("Foo: Cannot convert %d to a uint", val)); result = cast(uint)val * 100; } } . . . Foo A = new Foo; uint y = A; . . . Hmmm... this I could really use right now! --

Isn't there another way (or alternate design) to resolve the issue you have, Derek? I ask for several broad reasons; each of which is not intended to reflect in any manner upon your particular coding style/approach: 1) casting should be limited to special cases only. It should absolutely not be used as a panacea for design issues. I'm amazed how much writing is being done about it! Much like goto, I suppose. <sigh> 2) the compiler should catch as many errors as possible at compile time. Using opCast() to throw *runtime* exceptions is, in my opinion, akin to casting one's code unto the winds. 3) in exceptional circumstances, isn't it better to leverage an explicitly provided method? Within the class/struct? Arguing opCast() vs method() is talking syntactics rather than semantics ~ yet I find it hard to imagine the (deliberately?) ugly cast(X) being preferable over a clean method invocation. Oh well. 4) the apparently popular use of casts to make the method-selection algorithm 'work', simply shows a serious flaw in the design of the latter. I've raged about that aspect in the past, and it's a shame the energy of this thread isn't served in that direction instead. Spent quite a bit of time messing with opCast last year. Came to the (potentially flawed) conclusion that it's a bit of an outcast ~ so to speak. D would likely be better off without it. IMO. - Kris
Feb 22 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
Hi :)


 1) casting should be limited to special cases only. It should absolutely not be
 used as a panacea for design issues. I'm amazed how much writing is being done
 about it! Much like goto, I suppose. <sigh>

I tend to agree, but there is this issue with interfaces that I have that casting solves really neatly. Consider SomeInterface with 25 methods (like Java's List). If you want to implement it, you need to write and maintain all those 25 methods. OTOH, you can just be castable to it and need to write only one, using some generic implementation to handle everything, you just provide the data (of course, the functionality most probably isn't the same (like modifying the list in List's case), but I find it that in most cases it is not a big issue). Now, without overloadable casts, you can only handle one interface in this manner, which isn't that many...
 2) the compiler should catch as many errors as possible at compile time. Using
 opCast() to throw *runtime* exceptions is, in my opinion, akin to casting one's
 code unto the winds.

Yup, I agree.. Returning null should be the norm, as it is with non-user-defined casts..
 3) in exceptional circumstances, isn't it better to leverage an explicitly
 provided method? Within the class/struct? Arguing opCast() vs method() is
 talking syntactics rather than semantics ~ yet I find it hard to imagine the
 (deliberately?) ugly cast(X) being preferable over a clean method invocation.
Oh
 well.

Well, consider the above case. Let's say you also have a method that takes SomeInterface, and you call it 150 times in your project. Isn't casting it in one place better than calling func(obj.asSomeInterface()) 150 times? And maybe you later decide to change the method to use AnotherInterface. If you used casts, you only have two places to change (the method and the opCast()), if you use .asSomeInterface(), there's 150 places to change...
 4) the apparently popular use of casts to make the method-selection algorithm
 'work', simply shows a serious flaw in the design of the latter. I've raged
 about that aspect in the past, and it's a shame the energy of this thread isn't
 served in that direction instead.

I'd rather say that it's bad design to overload methods with parameters that are implicitly castable between each other.. IMO, of course :) xs0
Feb 22 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 23 Feb 2005 04:16:56 +0100, xs0 <xs0 xs0.com> wrote:
 1) casting should be limited to special cases only. It should  
 absolutely not be
 used as a panacea for design issues. I'm amazed how much writing is  
 being done
 about it! Much like goto, I suppose. <sigh>

I tend to agree, but there is this issue with interfaces that I have that casting solves really neatly. Consider SomeInterface with 25 methods (like Java's List). If you want to implement it, you need to write and maintain all those 25 methods. OTOH, you can just be castable to it and need to write only one, using some generic implementation to handle everything, you just provide the data (of course, the functionality most probably isn't the same (like modifying the list in List's case), but I find it that in most cases it is not a big issue). Now, without overloadable casts, you can only handle one interface in this manner, which isn't that many...

Good point.
 2) the compiler should catch as many errors as possible at compile  
 time. Using
 opCast() to throw *runtime* exceptions is, in my opinion, akin to  
 casting one's
 code unto the winds.

Yup, I agree.. Returning null should be the norm, as it is with non-user-defined casts..

I agree. I think consistency is a good thing here.
 3) in exceptional circumstances, isn't it better to leverage an  
 explicitly
 provided method? Within the class/struct? Arguing opCast() vs method()  
 is
 talking syntactics rather than semantics ~ yet I find it hard to  
 imagine the
 (deliberately?) ugly cast(X) being preferable over a clean method  
 invocation. Oh
 well.

Well, consider the above case. Let's say you also have a method that takes SomeInterface, and you call it 150 times in your project. Isn't casting it in one place better than calling func(obj.asSomeInterface()) 150 times? And maybe you later decide to change the method to use AnotherInterface. If you used casts, you only have two places to change (the method and the opCast()), if you use .asSomeInterface(), there's 150 places to change...

Good point.
 4) the apparently popular use of casts to make the method-selection  
 algorithm
 'work', simply shows a serious flaw in the design of the latter. I've  
 raged
 about that aspect in the past, and it's a shame the energy of this  
 thread isn't
 served in that direction instead.

I'd rather say that it's bad design to overload methods with parameters that are implicitly castable between each other.. IMO, of course :)

I tend to agree here also, however is it at all possible that the methods could provide more efficient, or a more exact 'something' for specific types than a cast and 1 method could? Regan
Feb 22 2005
prev sibling parent Kris <Kris_member pathlink.com> writes:
In article <cvgsj4$2dja$1 digitaldaemon.com>, xs0 says...
Hi :)


 1) casting should be limited to special cases only. It should absolutely not be
 used as a panacea for design issues. I'm amazed how much writing is being done
 about it! Much like goto, I suppose. <sigh>

I tend to agree, but there is this issue with interfaces that I have that casting solves really neatly. Consider SomeInterface with 25 methods (like Java's List). If you want to implement it, you need to write and maintain all those 25 methods. OTOH, you can just be castable to it and need to write only one, using some generic implementation to handle everything, you just provide the data (of course, the functionality most probably isn't the same (like modifying the list in List's case), but I find it that in most cases it is not a big issue). Now, without overloadable casts, you can only handle one interface in this manner, which isn't that many...

Ouch! :-)
 2) the compiler should catch as many errors as possible at compile time. Using
 opCast() to throw *runtime* exceptions is, in my opinion, akin to casting one's
 code unto the winds.

Yup, I agree.. Returning null should be the norm, as it is with non-user-defined casts..

opCast() is, by definition, a runtime call. Getting the compiler to invoke it at compile-time would certainly be interesting.
 3) in exceptional circumstances, isn't it better to leverage an explicitly
 provided method? Within the class/struct? Arguing opCast() vs method() is
 talking syntactics rather than semantics ~ yet I find it hard to imagine the
 (deliberately?) ugly cast(X) being preferable over a clean method invocation.
Oh
 well.

Well, consider the above case. Let's say you also have a method that takes SomeInterface, and you call it 150 times in your project. Isn't casting it in one place better than calling func(obj.asSomeInterface()) 150 times? And maybe you later decide to change the method to use AnotherInterface. If you used casts, you only have two places to change (the method and the opCast()), if you use .asSomeInterface(), there's 150 places to change...

Aye
 4) the apparently popular use of casts to make the method-selection algorithm
 'work', simply shows a serious flaw in the design of the latter. I've raged
 about that aspect in the past, and it's a shame the energy of this thread isn't
 served in that direction instead.

I'd rather say that it's bad design to overload methods with parameters that are implicitly castable between each other.. IMO, of course :)

There's the rub ~ a Haitian Divorce waiting to happen.
Feb 22 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 23 Feb 2005 02:25:40 +0000 (UTC), Kris wrote:

 In article <lx6y84tsdjq9.6hf2uroobfec$.dlg 40tude.net>, Derek Parnell says...

Agreed, this is not a bad compromise.

  void opCast(out T result);


Hmmm... this I could really use right now!


 
 Isn't there another way (or alternate design) to resolve the issue you have,
 Derek? I ask for several broad reasons; each of which is not intended to
reflect
 in any manner upon your particular coding style/approach:

Thanks Kris. Your questions and observations below a very good and valid ones.
 1) casting should be limited to special cases only. It should absolutely not be
 used as a panacea for design issues. I'm amazed how much writing is being done
 about it! Much like goto, I suppose. <sigh>

LOL. Yes it has become a little too emotional. I agree with your sentiments above. And we are talking about *explicit* casting, right? Currently, an explicit cast does one of two things, depending on what is getting cast to what... 1) To tell the compiler that some data, even though it has a data type of 'x', is to be treated as if it has a data type of 'y', and that no actual data is modified by this. 2) To tell the compiler that data of type 'x' is to be modified (converted) to a new storage format of data type 'y'. Now (1) is definitely a low-use, special circumstance, situation. It may even cause runtime errors, but that's okay because the coder has accepted responsibility of that due to the explicit cast. But (2) is a common activity of programs. To convert data from one format to another is done all the time. Because it is commonly required, it would be _nice_ to have some syntax sugar to help us (lazy?) coders. And maybe, an improved opCast is a way to achieve that sugary rush.
 2) the compiler should catch as many errors as possible at compile time. Using
 opCast() to throw *runtime* exceptions is, in my opinion, akin to casting one's
 code unto the winds.

Yes, in principle I agree. But consider the conversion process. Often conversions can only fail at run time. If we use an improved opCast in order to invoke a customized conversion function, then one would expect that runtime errors may occur. For example, if we have two classes, Foo and Bar, then aFoo = aBar; would trip up with the "cannot implicitly cast" error. But aFoo = cast(Foo)aBar; would first try to see if Bar has an opCast(Foo) defined, and if so invoke it, otherwise issue an error like it does today. If we knew that a runtime error is sometime possible we could write ... try { aFoo = cast(Foo) aBar;} catch ( ... whatever ... ) ...;
 3) in exceptional circumstances, isn't it better to leverage an explicitly
 provided method? Within the class/struct? Arguing opCast() vs method() is
 talking syntactics rather than semantics ~ yet I find it hard to imagine the
 (deliberately?) ugly cast(X) being preferable over a clean method invocation.
Oh
 well.

Yes, it is just syntax. aFoo = cast(Foo)aBar; verses aFoo = aBar.toFoo(); or aBar.toFoo( aFoo ); I suspect the 'cast' syntax is more amenable to templates though. template(T) { T a = new T; a = cast(T)parm; } (yeah, the above syntax is wrong but you get the idea )
 4) the apparently popular use of casts to make the method-selection algorithm
 'work', simply shows a serious flaw in the design of the latter. I've raged
 about that aspect in the past, and it's a shame the energy of this thread isn't
 served in that direction instead.

True, one could do ... class Bar{ void Convert(out Foo x) { .... }; void Convert(out uint x) { ... }; void Convert(out real x) { ... }; void Convert(out char[] x) { ... }; } Foo aFoo; real r; aBar.Convert( aFoo ); aBar.Convert( r ); Which is identical to the opCast() idea being discussed here, except that it is non-standard (everyone comes up with a new name for 'Convert'). This sort of method-selection is not, per se, indicative of a serious flaw in the design. The difference that has been suggested is ... class Bar{ void opCast(out Foo x) { .... }; void opCast(out uint x) { ... }; void opCast(out real x) { ... }; void opCast(out char[] x) { ... }; } Foo aFoo; real r; aFoo = cast(Foo)aBar; r = cast(real)aBar;
 Spent quite a bit of time messing with opCast last year. Came to the
 (potentially flawed) conclusion that it's a bit of an outcast ~ so to speak.  D
 would likely be better off without it. IMO.

I totally agree with you regards the current implementation of opCast. It is basically worthless. -- Derek Melbourne, Australia 23/02/2005 1:44:38 PM
Feb 22 2005
prev sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
xs0 wrote:
 Two questions:
 
 1) why inout not just out?

I know I had a reason... but I forget it now.
 2) why not have void return type, and in case of failure you can just 
 throw an exception yourself? presumably this would be a rare occasion, 
 and you can avoid a bunch of checks this way..

That's possible too. I just assumed the D runtime might have some use for a success/failure flag, for throwing a default exception or something. I admit I haven't looked at how the D compiler/runtime handle casting right now.
 
 Otherwise, not a bad idea at all, if you ask me. The only issue I can 
 see is that the result is not returned (as in "return something;"), so 
 it can't be used in expressions as easily (i.e. you need those temporary 
 variables, which probably complicates implementation significantly).

Yes that's most of my own personal issue with it, but it does give us multiple overloads for casting, and without having to add overload-on-return-type to the language spec. Although that could still possibly have its uses, but I'm not even diving into that can of worms. Also I would assume an opCast with a stable return type in its signature would be easier for the compiler anyhow. Keyword is of course 'assume'. -- Chris S
Feb 22 2005
parent xs0 <xs0 xs0.com> writes:
 2) why not have void return type, and in case of failure you can just 
 throw an exception yourself? presumably this would be a rare occasion, 
 and you can avoid a bunch of checks this way..

That's possible too. I just assumed the D runtime might have some use for a success/failure flag, for throwing a default exception or something. I admit I haven't looked at how the D compiler/runtime handle casting right now.

afaik, non-class types either always can or always can't be cast, so that is checked at compile time. casting between classes returns a null if the cast is not possible (that's why there's no instanceof operator, like in Java, you can just do if (cast(SomeClass)obj) {}
 Yes that's most of my own personal issue with it, but it does give us 
 multiple overloads for casting, and without having to add 
 overload-on-return-type to the language spec.

I was actually referring to compiling such code; you can't just replace cast(SomeType)obj with SomeType tmp; obj.opCast(tmp) because it could be in the middle of an expression. Although, now that I think about it, there is no need for that tmp variable, the compiler can use the result directly, unlike the coder..
  Also I would assume an opCast with a stable return type in its 
 signature would be easier for the compiler anyhow.  Keyword is of course 
 'assume'.

Well, I assume that too, and I agree that overloaded return types are a bad thing (except possibly for opCast(), because its not a "normal" function and because imho it has legitimate uses) xs0
Feb 22 2005