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

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

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

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

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.

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).

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.

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

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".

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.