Re: Hiding types
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();}
Re: Hiding types
On Fri, 30 May 2014 15:50:41 -0400, Philippe Sigaud
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
Re: Hiding types
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.
Re: Hiding types
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.
Re: Hiding types
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.
Re: Hiding types
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
Re: Hiding types
On Fri, 30 May 2014 16:09:59 -0400, Philippe Sigaud
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
Re: Hiding types
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.
Re: Hiding types
On Sat, May 31, 2014 at 6:39 AM, Dicebot via Digitalmars-d-learn 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.
Re: Hiding types
>> 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.
OK, I'll try that also. Thank you!
> 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 was trying to imitate some Haskell code in D. The idea was to play
with resources: from a File, create an OpenedFile which cannot be
created except by calling File.open(). And only FileOpened has a
.close() method.
Or something like this, anyway.
But I now realize that I was heading in a wrong direction: private is
not the way to do that: I want the user to know OpenedFile exists. I
just forbid him to create such a value except through File.open(). So
I guess :
struct OpenedFile {
@disable this...
}
is the way to go.
Now I just have to find an explanation on how to use this. I never
touched this part of D.
