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

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
>

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.

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

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

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

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.

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

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
>