"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsqz536na23k2f5@nrage.netwin.co.nz...
> On Wed, 18 May 2005 19:33:13 -0600, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
> > The problem with that is, you need to have the object /before/ you make the cast.
>
> True, assuming you're actually casting, which we're not.
>
> > The way I understand cst is: "take this chunck of memory, reinterpret it (or decode it) as if it was of this type", where "this type" is what you want to cast to.
>
> Sure. That is a description of what cast 'does'.
>
> I was simply saying that people use cast to disambiguate function calls already, extending it to do the same for functions overloaded by return-type is not a big step to make.
>
> As I noted, it wouldn't actually cast anything.
>
> >>  The objections seemed (to me to be) mostly differences of
> >> definition/concept, i.e. the idea that cast's 'purpose' is to convert
> >> data, not disambiguate function calls, so shouldn't be used here where
> >> no  'conversion' is actually required.
> >>  The fact remains (in my opinion) that it is used to disambiguate
> >> function  calls, eg. (using my example above):
> >>    foo(cast(int)a);
> >>  Does the cast convert data? debatable, in reality it's simply looking
> >> at  less of the data in this case, it's not changing the data itself
> >> (like it  would/could from long to float).
> >
> > something like
> > foo(5);
> > is a call that passes constants. Now, literal constants are part of the
> > language, and the type of a constant is determined by the language.
>
> Yep.
>
> > I think in C, 5 is an int, while 5.0 is a double.
>
> Yep.
>
> > I don't know what D does with that.
>
> The same thing, I believe.
>
> > But when you
> > cast(int)5
> > you are not removing ambiguity, you are writing an expression that
> > returns an "int".
>
> Technically you are correct. I'm saying there is another way to look at it and that is...
>
> When you decide to use cast in this case it is because you want to call 'that' function with 'that' value, ideally an overload would exist and you'd have no problem, however one doesn't. You know from experience to use cast to cause the correct overload to be selected. In effect you're using cast to select an overload.
>
> Technically cast causes it to cast the value, however primarily you don't care about the fact that it's casting, all you really care about is selecting the overload.
>
> > The data is already vilable, it's 5, and when you cast it to an int, you
> >   are essentially removing an ambiguity, but actually you are just
> > writing an expression that returns a known type (hence no ambiguity).
>
> Technically, correct.
>
> >>  Is conversion the reason the programmer put it there? debatable, the
> >> programmer simply wanted to call 'that' function with 'that' data.
> >> Cast/conversion just happens to be the only way to do that.
> >>  So, while return-type casting would not involve *any* conversion in
> >> *any*  sense, if the programmers intent is to call 'that' function then
> >> it's use  signals the same intent, IMHO.
> >>  Other solutions involved inventing a new syntax for 'selecting an
> >> overload'.
> >>  Regan
> >
> > A better way maybe to introduce a new concept, that is, a new keyword,
> > so instead of cast(type), we may say call(type) or something like that.
> >
> > But it would not be a "cast".
>
> Like I said, oppostion to using cast previously all wanted another keyword. Personally, I have no problem re-using cast for this.
>
> Regan

The concept is sound, but I would definately want to
stay away from using the "cast" keyword for that...
especially with a syntax that could be mistaken by the
compiler (or by a human programmer) for an actual
request to cast the return value to a specific type.

TZ

On Wed, 18 May 2005 20:50:35 -0700, Kyle Furlong <ky220@umail.ucsb.edu> wrote:
> Regan Heath wrote:
>>> This is why "cast" is a hackish solution (it doesn't even work).
>>   In your opinion :)
>>  Regan
>
> In my opinion also. Keywords should be unambiguous to the newbie, or at least make sense when explained. Using cast for all these purposes will add to the learning curve and also, IMHO, is hackish, as has already been stated.

Each to thier own. I don't think it's too much of a stretch.

> Also, doesnt the complier "know" which overload to call for the example:
>
> foo(cast(int)a);
>
> ?

Yes, because the cast tells it which one to call.

(I'm afraid I may have missed your point, there wasn't any more context to this example, it was meant for another purpose, perhaps if you propose another example I can answer more effectively)

Regan

In article <d6h2eb$t91$1@digitaldaemon.com>, Kyle Furlong says...
>
>Regan Heath wrote:
>> On Wed, 18 May 2005 21:34:36 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
>> 
>>> Regan Heath wrote:
>>>
>>>> On Wed, 18 May 2005 19:33:13 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
>>>>
>>>>> The problem with that is, you need to have the object /before/ you make  the cast.
>>>>
>>>>   True, assuming you're actually casting, which we're not.
>>>>
>>>
>>> you said it, it's not a cast, so why would we use cast when we actually  aren't casting anything?
>> 
>> 
>> I said it "people use cast to disambiguate function calls already".
>> 
>>>>> A better way maybe to introduce a new concept, that is, a new keyword,  so instead of cast(type), we may say call(type) or something  like that.
>>>>>
>>>>> But it would not be a "cast".
>>>>
>>>>   Like I said, oppostion to using cast previously all wanted
>>>> another   keyword. Personally, I have no problem re-using cast for this.
>>>>  Regan
>>>
>>>
>>> The problem is, we probably don't want to just "hack" the language together.
>> 
>> 
>> IMO using "cast" isn't a "hack". It's already used for the same 'purpose'  with normal function overload resolution, the only difference being that  in this case it doesn't actually have to 'cast' anything.
>> 
>>> Using "cast" to do something in special cases that's totally irrelevant  to its meaning just because we use it for the same purpose for something  else .... isn't exactly a good design IMHO.
>> 
>> 
>> That sentence was terribly confused but I think I follow. You're saying "using cast to select an overload is bad design" right?
>> 
>> So when we write this:
>>   foo(cast(int)a);
>> 
>> and do so in order to select an overload (rather than actually cast a value) we should use a new keyword?
>> 
>>> Also, this doesn't really remove any ambiguity, look at this example:
>>> ###
>>> int foo(){...}
>>> real foo(){...}
>>>
>>> void bar
>>> {
>>>      cast(int) foo(); //still ambigious
>>> }
>>> ###
>>> what are we doing here?
>> 
>> 
>> You're calling "int foo()"
>> 
>> Please read my other post for the rationale behind this: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/23847
>> 
>>> - calling the "real foo()" and casting it to "int"
>> 
>> 
>> If this is your intent you write:
>>   cast(int) cast(real) foo();
>> 
>>> This is why "cast" is a hackish solution (it doesn't even work).
>> 
>> 
>> In your opinion :)
>> 
>> Regan
>
>In my opinion also. Keywords should be unambiguous to the newbie, or at least make sense when explained. Using cast for all these purposes will add to the learning curve and also, IMHO, is hackish, as has already been stated.
>
>Also, doesnt the complier "know" which overload to call for the example:
>
>foo(cast(int)a);
>
>?

You guys got a bit off-topic I think.  My post was to explore the idea based on extending the C language; never did I say anything about D ;) - but very nice debate going on here.  You guys obviously know your stuff!  I'm not concerned with D's keyword cast() in the C language; and I agree that it could be a bit ambiguous and shouldn't be used as an all-in-one swiss-army knife.  I'll summarize my thoughts on all these issues in a response to my original post to keep the threads easy to follow.

Regards,
James Dunne

Regan Heath wrote:
> On Wed, 18 May 2005 21:34:36 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
> 
>> Using "cast" to do something in special cases that's totally irrelevant  to its meaning just because we use it for the same purpose for something  else .... isn't exactly a good design IMHO.
> 
> 
> That sentence was terribly confused but I think I follow. You're saying  "using cast to select an overload is bad design" right?
> 

I know the sentence is terrible, (it's a hackish sentence ;) )

> So when we write this:
>   foo(cast(int)a);
> 
> and do so in order to select an overload (rather than actually cast a  value) we should use a new keyword?

no, we ARE actually casting a value.

What I was saying is: we use casting to remove ambiguity from the passed parameter, but this doesn't mean we can use it to remove ambiguity from the return type of the function being called, because this has no meaning with respect to "cast"

> 
>> Also, this doesn't really remove any ambiguity, look at this example:
>> ###
>> int foo(){...}
>> real foo(){...}
>>
>> void bar
>> {
>>      cast(int) foo(); //still ambigious
>> }
>> ###
>> what are we doing here?
> 
> 
> You're calling "int foo()"
> 
> Please read my other post for the rationale behind this:
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/23847
> 
>> - calling the "real foo()" and casting it to "int"
> 
> 
> If this is your intent you write:
>   cast(int) cast(real) foo();
> 
>> This is why "cast" is a hackish solution (it doesn't even work).
> 
> 
> In your opinion :)
> 
> Regan

You make it work by even more hacking.

My point still shows that using "cast" is hackish.
When we cast function calls, we are casting the returned value to a new type, hence
cast(int) foo()
takes what ever value "foo" returns, and casts it to int.

See, "cast" already has a task that it performs when it preceeds a function call.

On Thu, 19 May 2005 04:18:45 +0000 (UTC), James Dunne wrote:


[snip]

> You guys got a bit off-topic I think.  My post was to explore the idea based on extending the C language; never did I say anything about D ;)

Did you notice the newsgroup's name? Why discuss C issues here and not in one of the DigitalMars C++ groups? Are you really surprised that we assumed you were talking about D?

Oh well, I guess you got plenty of theories anyhow. ;-)

-- 
Derek
Melbourne, Australia
19/05/2005 2:25:33 PM

Looks like it was my fault too ;)
Sorry.

Regan

On Thu, 19 May 2005 04:18:45 +0000 (UTC), James Dunne <james.jdunne@gmail.com> wrote:
> In article <d6h2eb$t91$1@digitaldaemon.com>, Kyle Furlong says...
>>
>> Regan Heath wrote:
>>> On Wed, 18 May 2005 21:34:36 -0600, Hasan Aljudy
>>> <hasan.aljudy@gmail.com>  wrote:
>>>
>>>> Regan Heath wrote:
>>>>
>>>>> On Wed, 18 May 2005 19:33:13 -0600, Hasan Aljudy
>>>>> <hasan.aljudy@gmail.com>  wrote:
>>>>>
>>>>>> The problem with that is, you need to have the object /before/ you
>>>>>> make  the cast.
>>>>>
>>>>>   True, assuming you're actually casting, which we're not.
>>>>>
>>>>
>>>> you said it, it's not a cast, so why would we use cast when we
>>>> actually  aren't casting anything?
>>>
>>>
>>> I said it "people use cast to disambiguate function calls already".
>>>
>>>>>> A better way maybe to introduce a new concept, that is, a new
>>>>>> keyword,  so instead of cast(type), we may say call(type) or
>>>>>> something  like that.
>>>>>>
>>>>>> But it would not be a "cast".
>>>>>
>>>>>   Like I said, oppostion to using cast previously all wanted
>>>>> another   keyword. Personally, I have no problem re-using cast for this.
>>>>>  Regan
>>>>
>>>>
>>>> The problem is, we probably don't want to just "hack" the language
>>>> together.
>>>
>>>
>>> IMO using "cast" isn't a "hack". It's already used for the same
>>> 'purpose'  with normal function overload resolution, the only difference
>>> being that  in this case it doesn't actually have to 'cast' anything.
>>>
>>>> Using "cast" to do something in special cases that's totally
>>>> irrelevant  to its meaning just because we use it for the same purpose
>>>> for something  else .... isn't exactly a good design IMHO.
>>>
>>>
>>> That sentence was terribly confused but I think I follow. You're saying
>>> "using cast to select an overload is bad design" right?
>>>
>>> So when we write this:
>>>   foo(cast(int)a);
>>>
>>> and do so in order to select an overload (rather than actually cast a
>>> value) we should use a new keyword?
>>>
>>>> Also, this doesn't really remove any ambiguity, look at this example:
>>>> ###
>>>> int foo(){...}
>>>> real foo(){...}
>>>>
>>>> void bar
>>>> {
>>>>      cast(int) foo(); //still ambigious
>>>> }
>>>> ###
>>>> what are we doing here?
>>>
>>>
>>> You're calling "int foo()"
>>>
>>> Please read my other post for the rationale behind this:
>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/23847
>>>
>>>> - calling the "real foo()" and casting it to "int"
>>>
>>>
>>> If this is your intent you write:
>>>   cast(int) cast(real) foo();
>>>
>>>> This is why "cast" is a hackish solution (it doesn't even work).
>>>
>>>
>>> In your opinion :)
>>>
>>> Regan
>>
>> In my opinion also. Keywords should be unambiguous to the newbie, or at
>> least make sense when explained. Using cast for all these purposes will
>> add to the learning curve and also, IMHO, is hackish, as has already
>> been stated.
>>
>> Also, doesnt the complier "know" which overload to call for the example:
>>
>> foo(cast(int)a);
>>
>> ?
>
> You guys got a bit off-topic I think.  My post was to explore the idea based on
> extending the C language; never did I say anything about D ;) - but very nice
> debate going on here.  You guys obviously know your stuff!  I'm not concerned
> with D's keyword cast() in the C language; and I agree that it could be a bit
> ambiguous and shouldn't be used as an all-in-one swiss-army knife.  I'll
> summarize my thoughts on all these issues in a response to my original post to
> keep the threads easy to follow.
>
> Regards,
> James Dunne

I'd like to throw this idea out there:

Make the return types of functions overloaded on multiple return types non-castable.  Ugh, I hate english... there's no better way to say that :-/. Yes, I'm a native speaker of the language, and I still hate it.  Boy, talk about ambiguity... Anyways...

If return types were non-castable (for overloaded functions) this would solve the implicit v. explicit cast fights (hehe, sounds like cat fights) going on.  I agree that if the compiler detects any ambiguity, the user should be at least warned, or error'd =).

Take this for example:

#class DBColumn {
#  public ushort opIndex(int i) { ... }
#  public int opIndex(int i) { ... }
#  public double opIndex(int i) { ... }
#  .
#  .
#}
#
#int main(char[][] args) {
#  DBColumn  col = new DBColumn(......);
#  int    col1;
#  ushort col2;
#  double col3;
#
#  col1 = col[0];  // ok - call int opIndex(0)
#  col2 = col[1];  // ok - call ushort opIndex(1)
#  // error! explicit cast; cannot determine which opIndex to call
#  col3 = cast(ushort)col[2];
#}

Implicit or explicit casting on the return-types should be disallowed.  The return-type should be treated specially as a non-castable type.  If the return value were passed to another function as a parameter which required the type to be casted/promoted to fit, it should be disallowed.  Semantics like this would be easy to implement into the current compiler - just add a non-castable flag to the type and if it has that flag set when it is to be casted, bail out. Generating error messages for these conditions should be fun!

There should be a different operation defined to allow explicit specification of the return type wanted in ambiguous situations, much like the call() operator mentioned earlier.

How does 'call(int) col[0]' look?  I suppose the opIndex function is a bad
example ;).

Someone please break my example!!  Proof by contradiction is the best proof there is. =P

Regards,
James Dunne

In article <opsqz9kl0623k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>Looks like it was my fault too ;)
>Sorry.
>
>Regan

No no, perfectly acceptable to assume one is discussing the D language in a D language newsgroup :).  My bad too.

My intent was to try the feature out on a simple compiler that I had source-code access to and could easily modify it.  Then I could *cough cough* come up with a nice proof-of-concept *cough* to present to Walter =D.

And in response to Derek, yes it seems I did get a fair amount of discussion and theories!  Please read my reply to my original post.

Regards,
James Dunne

"James Dunne" <james.jdunne@gmail.com> wrote in message news:d6h5h9$10hj$1@digitaldaemon.com...
> In article <opsqz9kl0623k2f5@nrage.netwin.co.nz>, Regan Heath says...
> >
> >Looks like it was my fault too ;)
> >Sorry.
> >
> >Regan
>
> No no, perfectly acceptable to assume one is discussing the D language in a D language newsgroup :).  My bad too.
>
> My intent was to try the feature out on a simple compiler that I had source-code access to and could easily modify it.  Then I could *cough cough* come up with a nice proof-of-concept *cough* to present to Walter =D.
>
> And in response to Derek, yes it seems I did get a fair amount of discussion and theories!  Please read my reply to my original post.
>
> Regards,
> James Dunne

I noticed that the original post was about modifying C,
but I never liked C anyway.  :)

True, the C language does have it's good points, but...
so does D... plus some good points of it's own.

With that fact in mind,
as well as the fact that you mentioned Walter not wanting
return type function overloading in D,
I figured best to suggest a connected but not equal possibility,
from which we could brain storm and hopefully find something
which Walter would find acceptable and would carry the
benefits of return type function overloading
without it's problems.

Sorry if that was out of line.

TZ

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:d6h46o$vbu$1@digitaldaemon.com...
>
*snip*
>
> no, we ARE actually casting a value.
>
> What I was saying is: we use casting to remove ambiguity from the passed parameter, but this doesn't mean we can use it to remove ambiguity from the return type of the function being called, because this has no meaning with respect to "cast"
>
*snip*

That actually makes sense... when you put it that way.  :)

TZ