Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
May 17, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
On Sat, 18 May 2013 01:13:00 +0200, Timothee Cour <thelastmammoth@gmail.com> wrote: > How to have alias this with an unaccessible member (x below). > Making the member private won't work as it'll disable all operations on > said member. > > ---- > struct A(T){ > T x; > //private T x would prevent alias this from doing anything useful > alias x this; > } > void main(){ > auto a=A!int; > a++;//should do a.x++; > static assert(!__traits(compiles,a.x)); // I want this to hold > > } > ---- The common way to do it is with a read-only property: struct A(T) { private T x; @property T get() { return x; } alias get this; } void main(){ auto a = A!int; a++; //should do a.x++; static assert(!__traits(compiles, a.x)); // This now holds! static assert(__traits(compiles, a.get)); // As does this, which may or may not be palatable. :( } This has been discussed numerous times before, but I believe the current behavior is here to stay. -- Simen |
May 18, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
Attachments:
| so in what you suggest, the exact same problem remains with 'get' being exposed instead of 'x', so the situation didn't improve...
looks like it's impossible to achieve this?
On Fri, May 17, 2013 at 4:24 PM, Simen Kjaeraas <simen.kjaras@gmail.com>wrote:
> On Sat, 18 May 2013 01:13:00 +0200, Timothee Cour < thelastmammoth@gmail.com> wrote:
>
> How to have alias this with an unaccessible member (x below).
>> Making the member private won't work as it'll disable all operations on said member.
>>
>> ----
>> struct A(T){
>> T x;
>> //private T x would prevent alias this from doing anything useful
>> alias x this;
>> }
>> void main(){
>> auto a=A!int;
>> a++;//should do a.x++;
>> static assert(!__traits(compiles,a.x)**); // I want this to hold
>>
>> }
>> ----
>>
>
>
> The common way to do it is with a read-only property:
>
> struct A(T) {
> private T x;
>
> @property
> T get() {
> return x;
> }
>
> alias get this;
> }
>
> void main(){
> auto a = A!int;
> a++; //should do a.x++;
> static assert(!__traits(compiles, a.x)); // This now holds!
> static assert(__traits(compiles, a.get)); // As does this, which may or
> may not be palatable. :(
> }
>
> This has been discussed numerous times before, but I believe the current behavior is here to stay.
>
> --
> Simen
>
|
May 19, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | On Saturday, 18 May 2013 at 00:12:13 UTC, Timothee Cour wrote:
> so in what you suggest, the exact same problem remains with 'get' being
> exposed instead of 'x', so the situation didn't improve...
>
> looks like it's impossible to achieve this?
With current implementation of "alias this" - no. It does not seem to be defined in spec / TDPL anywhere though.
|
May 19, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
On Sat, 18 May 2013 02:12:00 +0200, Timothee Cour <thelastmammoth@gmail.com> wrote: > so in what you suggest, the exact same problem remains with 'get' being > exposed instead of 'x', so the situation didn't improve... > > looks like it's impossible to achieve this? Well, there is also opDot: struct A(T) { private T x; T opDot() { return x; } } void main(){ auto a = A!int; a++; //should do a.x++; static assert(!__traits(compiles, a.x)); // This now holds! } However, now A!int is not an int (you can't pass it to functions taking int). -- Simen |
May 19, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On 05/19/2013 05:34 AM, Simen Kjaeraas wrote:
> Well, there is also opDot:
What is the state of opDot? According to the change log, it has been introduced as a part of "Version D 2.013 Apr 22, 2008" with the note "Added opDot, which is experimental only."
I will keep assuming that opDot does not exist. :) (However, it is being used by Unique an Ref in std.typecons.)
Ali
|
May 19, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On Sunday, 19 May 2013 at 14:33:32 UTC, Ali Çehreli wrote: > On 05/19/2013 05:34 AM, Simen Kjaeraas wrote: > >> Well, there is also opDot: > What is the state of opDot? According to the change log, it has been introduced as a part of "Version D 2.013 Apr 22, 2008" with the note "Added opDot, which is experimental only." > > I will keep assuming that opDot does not exist. :) (However, it is being used by Unique an Ref in std.typecons.) > > Ali http://forum.dlang.org/thread/tgwxjhyotclrhhxlgizb@forum.dlang.org http://forum.dlang.org/thread/gfold2$qrb$1@digitalmars.com |
May 22, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On Sunday, 19 May 2013 at 14:33:32 UTC, Ali Çehreli wrote:
> On 05/19/2013 05:34 AM, Simen Kjaeraas wrote:
>
>> Well, there is also opDot:
> What is the state of opDot? According to the change log, it has been introduced as a part of "Version D 2.013 Apr 22, 2008" with the note "Added opDot, which is experimental only."
>
> I will keep assuming that opDot does not exist. :) (However, it is being used by Unique an Ref in std.typecons.)
>
> Ali
is there anything you can do with opDot that you can't with alias this?
(aside from the ability to hide the member as being private, as raised in the OP; its a bit broken as mentioned 1 post above)
if not, it should deprecate.
|
May 22, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
Posted in reply to timotheecour | On Wednesday, May 22, 2013 18:18:34 timotheecour wrote: > On Sunday, 19 May 2013 at 14:33:32 UTC, Ali Çehreli wrote: > > On 05/19/2013 05:34 AM, Simen Kjaeraas wrote: > >> Well, there is also opDot: > > What is the state of opDot? According to the change log, it has been introduced as a part of "Version D 2.013 Apr 22, 2008" with the note "Added opDot, which is experimental only." > > > > I will keep assuming that opDot does not exist. :) (However, it > > is being used by Unique an Ref in std.typecons.) > > > > Ali > > is there anything you can do with opDot that you can't with alias this? > > (aside from the ability to hide the member as being private, as raised in the OP; its a bit broken as mentioned 1 post above) > > if not, it should deprecate. opDot is definitely supposed to be deprecated: http://d.puremagic.com/issues/show_bug.cgi?id=2327 but Daniel Murphy seems to have missed it on his list (http://dlang.org/deprecate.html), and it hasn't actually been deprecated yet (but then again, even delet hasn't been deprecated yet, so that just goes to show how slow we are to deprecate language features that are definitely supposed to get the axe). - Jonathan M Davis |
May 22, 2013 Re: how to have alias this with an unaccessible member? | ||||
---|---|---|---|---|
| ||||
Attachments:
| at least 'delete' is in the deprecated table (marked as will be deprecated
some time in the future)
so should opDot then.
On Wed, May 22, 2013 at 11:34 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> On Wednesday, May 22, 2013 18:18:34 timotheecour wrote:
> > On Sunday, 19 May 2013 at 14:33:32 UTC, Ali Çehreli wrote:
> > > On 05/19/2013 05:34 AM, Simen Kjaeraas wrote:
> > >> Well, there is also opDot:
> > > What is the state of opDot? According to the change log, it has been introduced as a part of "Version D 2.013 Apr 22, 2008" with the note "Added opDot, which is experimental only."
> > >
> > > I will keep assuming that opDot does not exist. :) (However, it
> > > is being used by Unique an Ref in std.typecons.)
> > >
> > > Ali
> >
> > is there anything you can do with opDot that you can't with alias this?
> >
> > (aside from the ability to hide the member as being private, as raised in the OP; its a bit broken as mentioned 1 post above)
> >
> > if not, it should deprecate.
>
> opDot is definitely supposed to be deprecated:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=2327
>
> but Daniel Murphy seems to have missed it on his list
> (http://dlang.org/deprecate.html), and it hasn't actually been deprecated
> yet
> (but then again, even delet hasn't been deprecated yet, so that just goes
> to
> show how slow we are to deprecate language features that are definitely
> supposed to get the axe).
>
> - Jonathan M Davis
>
|
Copyright © 1999-2021 by the D Language Foundation