Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 30, 2012 std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Is opImplicitCastTo a planned feature? It's only used in this type as I can see, and it doesn't add implicit casting. |
March 30, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Posted in reply to simendsjo | 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
|
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
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
|
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 |
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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
|
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
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
|
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 |
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 |
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 |
April 02, 2012 Re: std.typecons.Ref(T).opImplicitCastTo() | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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
|
Copyright © 1999-2021 by the D Language Foundation