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

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

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

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

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

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

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

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

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.

> 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

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

Xsss Zffff wrote:
> Yiii Wrrrr 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?

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

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.
>>  My argument is that it's not completely different, see my reasoning 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

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.
>>>
>> ...> Regan
>>
>> 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
The problem is, it isn't REALLY a cast that is wanted, it's a 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));

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.

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