www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.typecons.Ref(T).opImplicitCastTo()

reply simendsjo <simendsjo gmail.com> writes:
Is opImplicitCastTo a planned feature?
It's only used in this type as I can see, and it doesn't add implicit  
casting.
Mar 30 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 30, 2012 16:27:44 simendsjo wrote:

 Is opImplicitCastTo a planned feature?
 It's only used in this type as I can see, and it doesn't add implicit
 casting.


It's been discussed, but I don't think that it's ever been agreed upon. In 
theory, alias this is meant to deal with implicit casts. I don't know whay 
anything in Phobos would have such a function. And I don't know what the point 
of std.typecons.Ref really is. It's undocumented (and clearly is _intended_ to 
be undocumented given what the comment is started with). I suspect that it's 
an old idea that just hasn't been cleaned out. If you'll notice, it also has 
opDot, which is being removed from the language.

- Jonathan M Davis
Mar 30 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-03-2012 19:28, Jonathan M Davis wrote:

 On Friday, March 30, 2012 16:27:44 simendsjo wrote:

 Is opImplicitCastTo a planned feature?
 It's only used in this type as I can see, and it doesn't add implicit
 casting.


 It's been discussed, but I don't think that it's ever been agreed upon. In
 theory, alias this is meant to deal with implicit casts. I don't know whay
 anything in Phobos would have such a function. And I don't know what the point
 of std.typecons.Ref really is. It's undocumented (and clearly is _intended_ to
 be undocumented given what the comment is started with). I suspect that it's
 an old idea that just hasn't been cleaned out. If you'll notice, it also has
 opDot, which is being removed from the language.

 - Jonathan M Davis


But you can only have one alias this per type. It is outright 
incompatible with the idea of implicit cast operators. It's like 
restricting opCast to only one overload per function - a 
not-very-pragmatic decision if you ask me...

-- 
- Alex
Apr 01 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 02, 2012 05:41:00 Alex R=C3=B8nne Petersen wrote:

 On 30-03-2012 19:28, Jonathan M Davis wrote:

 On Friday, March 30, 2012 16:27:44 simendsjo wrote:

 Is opImplicitCastTo a planned feature?
 It's only used in this type as I can see, and it doesn't add impli=






cit

 casting.


=20
 It's been discussed, but I don't think that it's ever been agreed u=




pon. In

 theory, alias this is meant to deal with implicit casts. I don't kn=




ow whay

 anything in Phobos would have such a function. And I don't know wha=




t the

 point of std.typecons.Ref really is. It's undocumented (and clearly=




 is

 _intended_ to be undocumented given what the comment is started wit=




h). I

 suspect that it's an old idea that just hasn't been cleaned out. If=





 you'll notice, it also has opDot, which is being removed from the
 language.
=20
 - Jonathan M Davis


=20
 But you can only have one alias this per type. It is outright
 incompatible with the idea of implicit cast operators. It's like
 restricting opCast to only one overload per function - a
 not-very-pragmatic decision if you ask me...


alias this is not supposed to be restricted such that you can only have=
 one=20
per type. That's a temporary, implementation problem. TDPL specifically=
 talks=20
about having multiple alias thises per type.

- Jonathan M Davis
Apr 01 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 02-04-2012 06:25, Jonathan M Davis wrote:

 On Monday, April 02, 2012 05:41:00 Alex Rønne Petersen wrote:

 On 30-03-2012 19:28, Jonathan M Davis wrote:

 On Friday, March 30, 2012 16:27:44 simendsjo wrote:

 Is opImplicitCastTo a planned feature?
 It's only used in this type as I can see, and it doesn't add implicit
 casting.


 It's been discussed, but I don't think that it's ever been agreed upon. In
 theory, alias this is meant to deal with implicit casts. I don't know whay
 anything in Phobos would have such a function. And I don't know what the
 point of std.typecons.Ref really is. It's undocumented (and clearly is
 _intended_ to be undocumented given what the comment is started with). I
 suspect that it's an old idea that just hasn't been cleaned out. If
 you'll notice, it also has opDot, which is being removed from the
 language.

 - Jonathan M Davis


 But you can only have one alias this per type. It is outright
 incompatible with the idea of implicit cast operators. It's like
 restricting opCast to only one overload per function - a
 not-very-pragmatic decision if you ask me...


 alias this is not supposed to be restricted such that you can only have one
 per type. That's a temporary, implementation problem. TDPL specifically talks
 about having multiple alias thises per type.

 - Jonathan M Davis


What is the reason it hasn't been realized yet?

-- 
- Alex
Apr 01 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 02, 2012 07:23:23 Alex R=C3=B8nne Petersen wrote:

 On 02-04-2012 06:25, Jonathan M Davis wrote:

 alias this is not supposed to be restricted such that you can only =




have

 one
 per type. That's a temporary, implementation problem. TDPL specific=




ally

 talks about having multiple alias thises per type.
=20
 - Jonathan M Davis


=20
 What is the reason it hasn't been realized yet?


I don't know. While we're getting closer to having everything in TDPL=20=

implemented correctly each release, there's still plenty of stuff left =
to do,=20
and no one has tackled the alias this issue yet. I expect that it's not=
 an=20
entirely easy thing to fix and that other stuff has been higher priorit=
y.

http://d.puremagic.com/issues/show_bug.cgi?id=3D6083

The major thing being tackled this release has been const-correctness, =
and=20
it's not done yet (in spite of there now being a beta for 2.059). I bel=
ieve=20
that that's been one of Walter's major focuses this release cycle, and =
I=20
wouldn't really expect him to tackle anything else major until Object's=
 const-
correctness been sorted out. Nothing is stopping someone else from doin=
g it,=20
but no one has. Plenty of other stuff has been fixed though.

- Jonathan M Davis
Apr 01 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 02-04-2012 07:32, Jonathan M Davis wrote:

 On Monday, April 02, 2012 07:23:23 Alex Rønne Petersen wrote:

 On 02-04-2012 06:25, Jonathan M Davis wrote:

 alias this is not supposed to be restricted such that you can only have
 one
 per type. That's a temporary, implementation problem. TDPL specifically
 talks about having multiple alias thises per type.

 - Jonathan M Davis


 What is the reason it hasn't been realized yet?


 I don't know. While we're getting closer to having everything in TDPL
 implemented correctly each release, there's still plenty of stuff left to do,
 and no one has tackled the alias this issue yet. I expect that it's not an
 entirely easy thing to fix and that other stuff has been higher priority.

 http://d.puremagic.com/issues/show_bug.cgi?id=6083

 The major thing being tackled this release has been const-correctness, and
 it's not done yet (in spite of there now being a beta for 2.059). I believe
 that that's been one of Walter's major focuses this release cycle, and I
 wouldn't really expect him to tackle anything else major until Object's const-
 correctness been sorted out. Nothing is stopping someone else from doing it,
 but no one has. Plenty of other stuff has been fixed though.

 - Jonathan M Davis


To clarify, I mean to ask whether there are any design flaws in the 
strategy of having multiple alias this in one type, or whether it is 
purely an issue in the implementation (i.e. just plain hasn't been done 
yet)?

-- 
- Alex
Apr 02 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, April 02, 2012 09:37:04 Alex Rønne Petersen wrote:

 On 02-04-2012 07:32, Jonathan M Davis wrote:

 On Monday, April 02, 2012 07:23:23 Alex Rønne Petersen wrote:

 On 02-04-2012 06:25, Jonathan M Davis wrote:

 alias this is not supposed to be restricted such that you can only have
 one
 per type. That's a temporary, implementation problem. TDPL specifically
 talks about having multiple alias thises per type.
 
 - Jonathan M Davis


 
 What is the reason it hasn't been realized yet?


 
 I don't know. While we're getting closer to having everything in TDPL
 implemented correctly each release, there's still plenty of stuff left to
 do, and no one has tackled the alias this issue yet. I expect that it's
 not an entirely easy thing to fix and that other stuff has been higher
 priority.
 
 http://d.puremagic.com/issues/show_bug.cgi?id=6083
 
 The major thing being tackled this release has been const-correctness, and
 it's not done yet (in spite of there now being a beta for 2.059). I
 believe
 that that's been one of Walter's major focuses this release cycle, and I
 wouldn't really expect him to tackle anything else major until Object's
 const- correctness been sorted out. Nothing is stopping someone else from
 doing it, but no one has. Plenty of other stuff has been fixed though.
 
 - Jonathan M Davis


 
 To clarify, I mean to ask whether there are any design flaws in the
 strategy of having multiple alias this in one type, or whether it is
 purely an issue in the implementation (i.e. just plain hasn't been done
 yet)?


As far as I know, it's purely an implementation issue, but I don't know.

- Jonathan M Davis
Apr 02 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 31 March 2012 06:28, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 it also has
 opDot, which is being removed from the language.


Out of curiosity, what was opDot?

--
James Miller
Apr 01 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 02, 2012 15:36:01 James Miller wrote:

 On 31 March 2012 06:28, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 it also has
 opDot, which is being removed from the language.


 
 Out of curiosity, what was opDot?


An overload of the dot operator. So, if you had

A a = foo();
a.func();

and A implemented opDot, instead of A's func being called, the overloaded 
opDot would be called. I don't know exactly how it was implemented. It's 
either a D1-only thing or an early D2 thing, but I've never used it, and it's 
not supposed to be in the language anymore (though like a number of other 
features that are supposed to be gone, it may not have actually have been 
deprecated yet).

It's probably similar to how -> is overloadable in C++, which can then be 
useful for stuff like smart pointer types so that they can forward function 
calls to the object pointed to by the smart pointer.

- Jonathan M Davis
Apr 01 2012