Overloading an object to cast to another type:

class Another
{
	char[] str;
	this(char[] init) { str = init; }
	void opCast(out char* result) { result = toStringz(str); }
}

char[] foo = "hello world";
Another a = new Another(foo[0 .. 5]);
printf(a); //properly null-terminates

How about it?  :)

In article <buksgm$1vc1$1@digitaldaemon.com>, Vathix says...
>
>Overloading an object to cast to another type:
>
>class Another
>{
>	char[] str;
>	this(char[] init) { str = init; }
>	void opCast(out char* result) { result = toStringz(str); }
>}
>
>char[] foo = "hello world";
>Another a = new Another(foo[0 .. 5]);
>printf(a); //properly null-terminates
>
>How about it?  :)

This seems so natural that it shouldn't even be a question! :-)

wich is the same as operator Type() in c++, wich should be used in as less cases as possible. the implicit cast that happens can create such a ton of problems. nope. implicit casting should not be allowed

"Georg Wrede" <Georg_member@pathlink.com> schrieb im Newsbeitrag news:bulas9$2m2u$1@digitaldaemon.com...
>
> In article <buksgm$1vc1$1@digitaldaemon.com>, Vathix says...
> >
> >Overloading an object to cast to another type:
> >
> >class Another
> >{
> > char[] str;
> > this(char[] init) { str = init; }
> > void opCast(out char* result) { result = toStringz(str); }
> >}
> >
> >char[] foo = "hello world";
> >Another a = new Another(foo[0 .. 5]);
> >printf(a); //properly null-terminates
> >
> >How about it?  :)
>
> This seems so natural that it shouldn't even be a question! :-)
>
>

Wow! I hadn't looked at the example enough to realise that it was proposing implicit casting.

No way, no how!

"davepermen" <davepermen@hotmail.com> wrote in message news:bulb6u$2mkc$1@digitaldaemon.com...
> wich is the same as operator Type() in c++, wich should be used in as less cases as possible. the implicit cast that happens can create such a ton of problems. nope. implicit casting should not be allowed
>
> "Georg Wrede" <Georg_member@pathlink.com> schrieb im Newsbeitrag news:bulas9$2m2u$1@digitaldaemon.com...
> >
> > In article <buksgm$1vc1$1@digitaldaemon.com>, Vathix says...
> > >
> > >Overloading an object to cast to another type:
> > >
> > >class Another
> > >{
> > > char[] str;
> > > this(char[] init) { str = init; }
> > > void opCast(out char* result) { result = toStringz(str); }
> > >}
> > >
> > >char[] foo = "hello world";
> > >Another a = new Another(foo[0 .. 5]);
> > >printf(a); //properly null-terminates
> > >
> > >How about it?  :)
> >
> > This seems so natural that it shouldn't even be a question! :-)
> >
> >
>
>

i think if cast(Type) will switch over to a template syntax, a.k.a.
cast!(Type) we will soon write our own casts in that style.. just like
static_cast!(Type) or similar.. any_cast!(Type), lexical_cast!(Type) etc..

this can be done even now yet.. so it's easy.. but we need type deduction actually..

uint x = 10;
char[] str = "x = ";
str ~= lexical_cast!(char[],uint)(x);

hm.. if type deduction can not be implemented as is, i propose a new thing:

typeof with the ? operator.. ?x is typeof(x)

so we could at least write:

uint x = 10;
char[] str = "x = ";
str ~= lexical_cast!(char[],?x)(x);

of course,

str ~= lexical_cast!(char[])(x); would be best..

"Matthew" <matthew.hat@stlsoft.dot.org> schrieb im Newsbeitrag news:bulf2o$2u6r$1@digitaldaemon.com...
> Wow! I hadn't looked at the example enough to realise that it was
proposing
> implicit casting.
>
> No way, no how!
>
> "davepermen" <davepermen@hotmail.com> wrote in message news:bulb6u$2mkc$1@digitaldaemon.com...
> > wich is the same as operator Type() in c++, wich should be used in as
less
> > cases as possible. the implicit cast that happens can create such a ton
of
> > problems. nope. implicit casting should not be allowed
> >
> > "Georg Wrede" <Georg_member@pathlink.com> schrieb im Newsbeitrag news:bulas9$2m2u$1@digitaldaemon.com...
> > >
> > > In article <buksgm$1vc1$1@digitaldaemon.com>, Vathix says...
> > > >
> > > >Overloading an object to cast to another type:
> > > >
> > > >class Another
> > > >{
> > > > char[] str;
> > > > this(char[] init) { str = init; }
> > > > void opCast(out char* result) { result = toStringz(str); }
> > > >}
> > > >
> > > >char[] foo = "hello world";
> > > >Another a = new Another(foo[0 .. 5]);
> > > >printf(a); //properly null-terminates
> > > >
> > > >How about it?  :)
> > >
> > > This seems so natural that it shouldn't even be a question! :-)
> > >
> > >
> >
> >
>
>

Ok, I don't know enough about this to argue.
But there really should be an easy way to
use c and d strings in a mixed environment.
Easy meaning less typing.


In article <bulb6u$2mkc$1@digitaldaemon.com>, davepermen says...
>
>wich is the same as operator Type() in c++, wich should be used in as less cases as possible. the implicit cast that happens can create such a ton of problems. nope. implicit casting should not be allowed
>
>"Georg Wrede" <Georg_member@pathlink.com> schrieb im Newsbeitrag news:bulas9$2m2u$1@digitaldaemon.com...
>>
>> In article <buksgm$1vc1$1@digitaldaemon.com>, Vathix says...
>> >
>> >Overloading an object to cast to another type:
>> >
>> >class Another
>> >{
>> > char[] str;
>> > this(char[] init) { str = init; }
>> > void opCast(out char* result) { result = toStringz(str); }
>> >}
>> >
>> >char[] foo = "hello world";
>> >Another a = new Another(foo[0 .. 5]);
>> >printf(a); //properly null-terminates
>> >
>> >How about it?  :)
>>
>> This seems so natural that it shouldn't even be a question! :-)
>>
>>
>
>

davepermen wrote:
> wich is the same as operator Type() in c++, wich should be used in as less
> cases as possible. the implicit cast that happens can create such a ton of
> problems. nope. implicit casting should not be allowed

Implicit casting is all right /so long as/ you distinguish between information-increasing casts and information-denuding casts; upcasts and downcasts.  Casting from float to int is a downcast; we lose information.  The opposite direction is an upcast; the new type has as much information or more (for the purposes of casting).  With this information we can solve an equation's casting, handle explicit implicit casting, and generate cogent error messages in case of conflict, such as if there's a mutual upcast.

C++ is a particular mess when it comes to this operator.  There's no reversability, there's two ways to do one thing, it makes it impossible for implementations to produce a legible error report, and it treats a two-way street as if there's only one way you should want to go.  Bloody awful.  Don't judge a concept based on a broken implementation.

i'm not sure. i don't really like it by default.

i don't even use implicit casts if i code with integers and floats, just to make sure i code it really the way i want..

"Burton Radons" <loth@users.sourceforge.net> schrieb im Newsbeitrag news:bunpiu$gtv$1@digitaldaemon.com...
> davepermen wrote:
> > wich is the same as operator Type() in c++, wich should be used in as
less
> > cases as possible. the implicit cast that happens can create such a ton
of
> > problems. nope. implicit casting should not be allowed
>
> Implicit casting is all right /so long as/ you distinguish between information-increasing casts and information-denuding casts; upcasts and downcasts.  Casting from float to int is a downcast; we lose information.  The opposite direction is an upcast; the new type has as much information or more (for the purposes of casting).  With this information we can solve an equation's casting, handle explicit implicit casting, and generate cogent error messages in case of conflict, such as if there's a mutual upcast.
>
> C++ is a particular mess when it comes to this operator.  There's no reversability, there's two ways to do one thing, it makes it impossible for implementations to produce a legible error report, and it treats a two-way street as if there's only one way you should want to go.  Bloody awful.  Don't judge a concept based on a broken implementation.
>

Vathix wrote:
> Overloading an object to cast to another type:

I agree that we need something like that for symmetry. But to be used sparingly. In C++ we had explicit constructors. Maybe also opExplicitCast?

> class Another
> {
>     char[] str;
>     this(char[] init) { str = init; }
>     void opCast(out char* result) { result = toStringz(str); }

or even, let the return type be the type to cast to.

    char * opCast() { return toStringz(str); }

Then i also have another idea. Some functions must be allowed to always implicitly cast their input, even if only explicit cast is defined for the input. Example:

void sillyPrint(cast(char*) string)  { /+...+/ }

Now, given any type, for which explicit or implicit cast is defined, it would be implicitly cast to char* when fed to this function.

-eye

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bus46u$1ljc$1@digitaldaemon.com...
> Vathix wrote:
> > Overloading an object to cast to another type:
>
> I agree that we need something like that for symmetry. But to be used sparingly. In C++ we had explicit constructors. Maybe also opExplicitCast?
>
> > class Another
> > {
> >     char[] str;
> >     this(char[] init) { str = init; }
> >     void opCast(out char* result) { result = toStringz(str); }
>
> or even, let the return type be the type to cast to.
>
>      char * opCast() { return toStringz(str); }

  type opExplicitCast()

 is a good idea

>
> Then i also have another idea. Some functions must be allowed to always implicitly cast their input, even if only explicit cast is defined for the input. Example:
>
> void sillyPrint(cast(char*) string)  { /+...+/ }
>
> Now, given any type, for which explicit or implicit cast is defined, it would be implicitly cast to char* when fed to this function.

Nope. Explicit generalisation through shims (http://www.cuj.com/documents/s=8681/cuj0308wilson/) is a far better approach. It has all of the benefits, without any of the gotchas.

Matthew

P.S. btw, Ilya, did I tell you that the last chapter in the book is Properties, as inspired by your good self? :)