I'm trying to 'hide' a type, so as not to see it outside its module. I want to control the way it's created and used.

I know of Voldemort types and '@disable this', but for now I'm just trying to use 'private'. Halas, it seems it can be circumvented:

*********

module A;

private struct Hidden {}

Hidden foo() { return Hidden();}

*********

module B;

import A;

void main() {
    typeof(foo()) h;
}

*********

Am I misunderstanding something or is that a bug?

On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:
> Am I misunderstanding something or is that a bug?

Try: auto foo() { return Hidden();}

On Fri, 30 May 2014 15:50:41 -0400, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> I'm trying to 'hide' a type, so as not to see it outside its module. I want to control the way it's created and used.
>
> I know of Voldemort types and '@disable this', but for now I'm just trying to use 'private'. Halas, it seems it can be circumvented:
>
> *********
>
> module A;
>
> private struct Hidden {}
>
> Hidden foo() { return Hidden();}
>
> *********
>
> module B;
>
> import A;
>
> void main() {
>      typeof(foo()) h;
> }
>
> *********
>
> Am I misunderstanding something or is that a bug?

Even voldemort types can be declared that way. If you want an opaque struct, you need to return it by pointer. Otherwise, the user must be able to know what type it is (otherwise, how would he use it?)

-Steve

On Friday, 30 May 2014 at 19:54:00 UTC, safety0ff wrote:
> On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:
>> Am I misunderstanding something or is that a bug?
>
> Try: auto foo() { return Hidden();}

I'm not seeing any difference? I'm still able to create a value of type Hidden in an external module.

On Friday, 30 May 2014 at 19:54:00 UTC, safety0ff wrote:
> On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:
>> Am I misunderstanding something or is that a bug?
>
> Try: auto foo() { return Hidden();}

This is incorrect, please ignore.

On Friday, 30 May 2014 at 20:02:40 UTC, Steven Schveighoffer wrote:

> If you want an opaque struct, you need to return it by pointer.

What do you mean? Like this?

Hidden* foo() { return new Hidden();}

?

> Otherwise, the user must be able to know what type it is (otherwise, how would he use it?)

I just fear that by using internal, public, functions, the user might get access to a private type. I guess the D answer to that is to make foo private also. That makes sense.

I now realize that I implicitly considered 'private' to be transitive (or viral). That is that:

Hidden foo() { return Hidden();}

as foo is returning a value from a private type, it should be considered private also. By the compiler, I mean.

Philippe Sigaud:

> as foo is returning a value from a private type, it should be considered private also.

I think this was discussed, but I don't know why Walter didn't design like that. Perhaps someone else can give you an answer.

Bye,
bearophile

On Fri, 30 May 2014 16:09:59 -0400, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> On Friday, 30 May 2014 at 20:02:40 UTC, Steven Schveighoffer wrote:
>
>> If you want an opaque struct, you need to return it by pointer.
>
> What do you mean? Like this?
>
> Hidden* foo() { return new Hidden();}
>
> ?

Yes, this way you can control all aspects of the construction and use. You wouldn't need to make it private even, just don't lay out the struct in the normal import:

struct Hidden;

I think you would need to use a .di file to do this.

>
>> Otherwise, the user must be able to know what type it is (otherwise, how would he use it?)
>
> I just fear that by using internal, public, functions, the user might get access to a private type. I guess the D answer to that is to make foo private also. That makes sense.

You can make the struct's methods and data all private, which would prevent any useful access to it. But I don't know your use case.

> I now realize that I implicitly considered 'private' to be transitive (or viral). That is that:
>
> Hidden foo() { return Hidden();}
>
> as foo is returning a value from a private type, it should be considered private also. By the compiler, I mean.

No, private just makes the symbol not directly accessible. Since foo is not private, it's accessible.

-Steve

private in D does not provide any strong guarantees, it only controls direct access to the symbol. You effectively want some sort of strict internal linkage attribute which does not exist in D.

On Sat, May 31, 2014 at 6:39 AM, Dicebot via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
> private in D does not provide any strong guarantees, it only controls direct access to the symbol. You effectively want some sort of strict internal linkage attribute which does not exist in D.

Indeed. I will learn to use '@disable this', then.