www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Possible regression (2.060 -> 2.061) with member access

reply Benjamin Thaut <code benjamin-thaut.de> writes:
The following reduced source code would compile just fine with dmd 2.060 
but does no longer compile with dmd 2.061:

file a.d:
module a;

import b;

template getType(T)
{
   alias typeof(T.i) getType;
}

void main(string[] args)
{
   alias getType!Foo t;
}


file b.d:
module b;

struct Foo
{
   private int i;
}


This breaks all kind of low level functionality I did build. It breaks 
both my serialization code and runtime type information system. Because 
in both use cases I need to be able to access the type of a protected or 
private member.

Has this been "fixed" intentionally? Or is this a regression? If it has 
been "fixed" what would be a workaround to get the type of Foo.i 
(outside of the b module) ?

Kind Regards
Benjamin Thaut
Feb 09 2013
next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
--f46d044306b033ab6a04d54c8096
Content-Type: text/plain; charset=UTF-8

2013/2/10 Benjamin Thaut <code benjamin-thaut.de>


 The following reduced source code would compile just fine with dmd 2.060
 but does no longer compile with dmd 2.061:

 file a.d:
 module a;

 import b;

 template getType(T)
 {
   alias typeof(T.i) getType;
 }

 void main(string[] args)
 {
   alias getType!Foo t;
 }


 file b.d:
 module b;

 struct Foo
 {
   private int i;
 }


 This breaks all kind of low level functionality I did build. It breaks
 both my serialization code and runtime type information system. Because in
 both use cases I need to be able to access the type of a protected or
 private member.

 Has this been "fixed" intentionally? Or is this a regression?




It's introduced by fixing issue 5385, so at least not a regression



 If it has been "fixed" what would be a workaround to get the type of Foo.i
 (outside of the b module)



You can use built-in 'tupleof' property, which still bypass access
modifier.

Kenji Hara

--f46d044306b033ab6a04d54c8096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2013/2/10 Benjamin Thaut <span dir=3D"ltr">&lt;<a href=3D"=
mailto:code benjamin-thaut.de" target=3D"_blank">code benjamin-thaut.de</a>=
&gt;</span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
The following reduced source code would compile just fine with dmd 2.060 bu=
t does no longer compile with dmd 2.061:<br>
<br>
file a.d:<br>
module a;<br>
<br>
import b;<br>
<br>
template getType(T)<br>
{<br>
=C2=A0 alias typeof(T.i) getType;<br>
}<br>
<br>
void main(string[] args)<br>
{<br>
=C2=A0 alias getType!Foo t;<br>
}<br>
<br>
<br>
file b.d:<br>
module b;<br>
<br>
struct Foo<br>
{<br>
=C2=A0 private int i;<br>
}<br>
<br>
<br>
This breaks all kind of low level functionality I did build. It breaks both=
 my serialization code and runtime type information system. Because in both=
 use cases I need to be able to access the type of a protected or private m=
ember.<br>

<br>
Has this been &quot;fixed&quot; intentionally? Or is this a regression?</bl=
ockquote><div><br></div><div style>It&#39;s introduced by fixing=C2=A0issue=
 5385, so at least=C2=A0not a regression</div><div>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex">
If it has been &quot;fixed&quot; what would be a workaround to get the type=
 of Foo.i (outside of the b module)=C2=A0<br></blockquote><div><br></div><d=
iv style>You can use built-in &#39;tupleof&#39; property, which still bypas=
s access modifier.=C2=A0<br>
</div><div style><br></div><div style>Kenji Hara</div></div></div></div>

--f46d044306b033ab6a04d54c8096--
Feb 09 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 09.02.2013 16:40, schrieb kenji hara:

 You can use built-in 'tupleof' property, which still bypass access
 modifier.



Will they continue to do so, or will this also be fixed? We should at 
least have some way to do low level work like serialization.

Kind Regards
Benjamin Thaut
Feb 09 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-09 16:20, Benjamin Thaut wrote:


 Has this been "fixed" intentionally? Or is this a regression? If it has
 been "fixed" what would be a workaround to get the type of Foo.i
 (outside of the b module) ?



The workaround would be to use .tupleof:

https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L237

-- 
/Jacob Carlborg
Feb 09 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 9 February 2013 at 15:52:04 UTC, Benjamin Thaut 
wrote:

 Am 09.02.2013 16:40, schrieb kenji hara:

 You can use built-in 'tupleof' property, which still bypass 
 access
 modifier.



 Will they continue to do so, or will this also be fixed? We 
 should at least have some way to do low level work like 
 serialization.

 Kind Regards
 Benjamin Thaut



According to my private-related DIP - yes, they will continue, 
and there have been no objections on this part.
Feb 09 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/9/13, kenji hara <k.hara.pg gmail.com> wrote:

 It's introduced by fixing issue 5385, so at least not a regression



Perhaps we could relax the rule and allow bypassing access
restrictions when using typeof().

There are similar bugs opened about purity, where e.g. you can't check
the length of an impure static array in a pure function (even though
it will never change length).

I think we'll have to define in the spec exactly what is and isn't
allowed and then implement this properly, otherwise we risk fixing bug
for person #1 which ends up breaking code for person #2 (which is
exactly what happened with fixing 5385).
Feb 09 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-09 21:51, Nick Sabalausky wrote:


 I think that's asking for confusion to have different visibility rules
 inside and outside typeof().

 The typical way to access private members when really needed is via a
 reflection mechanism, and we already have a way to do that as two
 people have mentioned.



Couldn't typeof() be considered part of a reflection mechanism?

-- 
/Jacob Carlborg
Feb 09 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 10.02.2013 11:21, schrieb Dicebot:

 On Saturday, 9 February 2013 at 22:54:09 UTC, Jacob Carlborg wrote:

 On 2013-02-09 21:51, Nick Sabalausky wrote:


 I think that's asking for confusion to have different visibility rules
 inside and outside typeof().

 The typical way to access private members when really needed is via a
 reflection mechanism, and we already have a way to do that as two
 people have mentioned.



 Couldn't typeof() be considered part of a reflection mechanism?



 May be, but definitely not an advanced librar'ish one - contrary to
 .tupleof and some __traits is is a pretty common guest in user code.



Really? I'm using typeof all over the place in my user code.
Feb 10 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 10.02.2013 11:55, schrieb Dicebot:

 On Sunday, 10 February 2013 at 10:22:59 UTC, Benjamin Thaut wrote:

 Really? I'm using typeof all over the place in my user code.



 That is exactly what I have just said :) And reason why it should behave
 according to usual protection attribute rules.



Oh ok, then I misunderstood your argument.
Feb 10 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 9 Feb 2013 21:34:54 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 On 2/9/13, kenji hara <k.hara.pg gmail.com> wrote:

 It's introduced by fixing issue 5385, so at least not a regression



 Perhaps we could relax the rule and allow bypassing access
 restrictions when using typeof().



I think that's asking for confusion to have different visibility rules
inside and outside typeof().

The typical way to access private members when really needed is via a
reflection mechanism, and we already have a way to do that as two
people have mentioned.
Feb 09 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 09 Feb 2013 23:54:09 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-02-09 21:51, Nick Sabalausky wrote:
 

 I think that's asking for confusion to have different visibility
 rules inside and outside typeof().

 The typical way to access private members when really needed is via
 a reflection mechanism, and we already have a way to do that as two
 people have mentioned.



 Couldn't typeof() be considered part of a reflection mechanism?
 



Yea, but not the part of reflection I was trying to refer to. Wasn't
sure what to call it besides the overly-general "reflection mechanism".
Feb 09 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 9 February 2013 at 22:54:09 UTC, Jacob Carlborg 
wrote:

 On 2013-02-09 21:51, Nick Sabalausky wrote:


 I think that's asking for confusion to have different 
 visibility rules
 inside and outside typeof().

 The typical way to access private members when really needed 
 is via a
 reflection mechanism, and we already have a way to do that as 
 two
 people have mentioned.



 Couldn't typeof() be considered part of a reflection mechanism?



May be, but definitely not an advanced librar'ish one - contrary 
to .tupleof and some __traits is is a pretty common guest in user 
code.
Feb 10 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 10 February 2013 at 10:22:59 UTC, Benjamin Thaut wrote:

 Really? I'm using typeof all over the place in my user code.



That is exactly what I have just said :) And reason why it should 
behave according to usual protection attribute rules.
Feb 10 2013