Re: how to have alias this with an unaccessible member?

2013-05-23 Thread Timothee Cour 
This won't do for the same reason: now 'get' is made public so we're back
to the same problem (inverting roles of x and get).

However what about changing the behavior of alias this as follows:

when a member/method x is private, alias x this behaves as if x was not
declared private.

I think this makes sense:
* this allows protection (x is an implementation detail) so that 'this'
behaves exactly as 'x'
* also, without this change of behavior, alias x this would not make any
sense in terms of behavior outside the class (inside behavior should just
access x directly)

Then, when multiple alias this statements will become allowed in D, we
would have implemented the same concept as embedding in GO.

Any thoughts?


here's what we would have:

struct A(T){
  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++; //semantic change: even though x is private, all
its methods are un-privated through alias this.
  static assert(!__traits(compiles,a.x));
}





On Sat, May 18, 2013 at 1:33 AM, Dicebot m.stras...@gmail.com wrote:

 Will this do?

 


 struct A(T)
 {
 private T x;

 ref T get()

 {
 return x;
 }

 alias get this;
 }

 -

Re: how to have alias this with an unaccessible member?

2013-05-22 Thread timotheecour 

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.

Re: how to have alias this with an unaccessible member?

2013-05-22 Thread Jonathan M Davis 
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

Re: how to have alias this with an unaccessible member?

2013-05-22 Thread Timothee Cour 
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 jmdavisp...@gmx.comwrote:

 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

Re: how to have alias this with an unaccessible member?

2013-05-19 Thread Dicebot 

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.

Re: how to have alias this with an unaccessible member?

2013-05-19 Thread Simen Kjaeraas 
On Sat, 18 May 2013 02:12:00 +0200, Timothee Cour  
thelastmamm...@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

Re: how to have alias this with an unaccessible member?

2013-05-19 Thread Ali Çehreli 

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

Re: how to have alias this with an unaccessible member?

2013-05-19 Thread Namespace 

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/tgwxjhyotclrhhxlg...@forum.dlang.org
http://forum.dlang.org/thread/gfold2$qrb$1...@digitalmars.com

Re: how to have alias this with an unaccessible member?

2013-05-18 Thread Dicebot 

Will this do?



struct A(T)
{
private T x;

ref T get()
{
return x;
}

alias get this;
}

-

Re: how to have alias this with an unaccessible member?

2013-05-18 Thread Dicebot 

Btw, fun fact. This code crashes 2.063 beta:



struct A(T)
{
private T x;
alias y = x;
alias y this;
}



dmd: aliasthis.c:114: virtual void AliasThis::semantic(Scope*): 
Assertion `t' failed.

how to have alias this with an unaccessible member?

2013-05-17 Thread Timothee Cour 
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

}

Re: how to have alias this with an unaccessible member?

2013-05-17 Thread Simen Kjaeraas 
On Sat, 18 May 2013 01:13:00 +0200, Timothee Cour  
thelastmamm...@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

Re: how to have alias this with an unaccessible member?

2013-05-17 Thread Timothee Cour 
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.kja...@gmail.comwrote:

 On Sat, 18 May 2013 01:13:00 +0200, Timothee Cour 
 thelastmamm...@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