www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - public aliases to private/package symbols

reply "Martin Nowak" <dawg dawgfoto.de> writes:
Should aliases be allowed to raise the accessibility of a symbol?

http://d.puremagic.com/issues/show_bug.cgi?id=4533
http://d.puremagic.com/issues/show_bug.cgi?id=6013
Jan 24 2012
next sibling parent Trass3r <un known.com> writes:
 Should aliases be allowed to raise the accessibility of a symbol?

Yeah I do use that by having a private template function and public aliases to certain instances.
Jan 24 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Martin Nowak" <dawg dawgfoto.de> wrote in message 
news:mailman.782.1327427928.16222.digitalmars-d puremagic.com...
 Should aliases be allowed to raise the accessibility of a symbol?

 http://d.puremagic.com/issues/show_bug.cgi?id=4533
 http://d.puremagic.com/issues/show_bug.cgi?id=6013

Yes.
Jan 24 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jfnag6$317n$1 digitalmars.com...
 "Martin Nowak" <dawg dawgfoto.de> wrote in message 
 news:mailman.782.1327427928.16222.digitalmars-d puremagic.com...
 Should aliases be allowed to raise the accessibility of a symbol?

 http://d.puremagic.com/issues/show_bug.cgi?id=4533
 http://d.puremagic.com/issues/show_bug.cgi?id=6013

Yes.

How else are you going to separate the interface for the internal implementation of a template from its for-public-consumption interface? This whole issue is literally *NO* different from "Should a public pointer/reference be allowed to point to private data?" or "Should a public function be allowed to expose a private one?" The answer is: "Obviously yes". I don't understand why anyone thinks this is any different just because they're aliases instead of pointers/references/functions/etc. All the arguments against public alias to private symbols apply equally to these questions too, and in those cases nobody would even question it. What is it about aliases that suddenly trips people up and makes them think the whole concept of accessibility should be flipped around on its head?
Jan 24 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2012 12:09 AM, Peter Alexander wrote:
 On Tuesday, 24 January 2012 at 22:26:37 UTC, Nick Sabalausky wrote:
 This whole issue is literally *NO* different from "Should a public
 pointer/reference be allowed to point to private data?" or "Should a
 public function be allowed to expose a private one?" The answer is:
 "Obviously yes".

Things can be obvious in different ways. For example, one could argue that it's also obvious that an alias should behave exactly the same as the thing it aliases. Allowing aliases to change protection would break that.

The accessibility of something is not part of its behavior.
 For the record, I agree that the answer should be "yes", but it's not a
 decision that should be made rashly. If we aren't careful, we could
 introduce a hole in the protection system in a non-obvious way. C++'s
 protection system has a non-obvious hole:
 http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html

Non-obvious? Perfectly obvious: Access checking rules do not apply to names in explicit template instantiations. It is an explicit rule that states access checking is subverted.
 Again, I agree, but what's obvious isn't always true, so it needs to be
 considered in depth.

Accessibility-raising aliases are trivially safe, because the alias declaration must have access to the aliased symbol.
Jan 24 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:jzvidktaqmkptrooimvt dfeed.kimsufi.thecybershadow.net...
 On Wednesday, 25 January 2012 at 00:08:25 UTC, Timon Gehr wrote:
 Accessibility-raising aliases are trivially safe, because the alias 
 declaration must have access to the aliased symbol.

You are probably right about not introducing holes, but I can imagine this getting tricky, and perhaps confusing in some cases. Here are some off the top of my head. module A; private class Foo {} public alias Foo Bar; In other modules that import A: Bar b = new typeof(b)(); // typeof(b) is Foo. Is this allowed? T foo(T)(T x) { return new T(); } Bar b; b = foo(b); // T is deduced to Foo, should this work? Bar b = new Bar(); mixin("b = new " ~ typeof(b).stringof ~ "();"); // This fails, the string is "Foo"

In all the above, the type *should* be Bar, not Foo (although it might not currently be - I'd consider that something that needs to be changed). Bar should refer to Foo *behind the scenes*, and as such, the fact that it refers to something else behind the scenes is totally irrelevent. This would also seem to be related to issue of error messages currently referring to the underlying type insted of the aliased type (which I'm convinced is the wrong way round).
 Just thinking about this has made me change my position. Accessibility 
 raising aliases should not be allowed. It's a minefield.

The issue is not with aliases, accessability already has a natural grey area: ==================== module lib; private struct Foo {} // Should any of these be allowed? public Foo getFoo() { return Foo(); } public void takeFoo(Foo f) {} struct Bar { Foo f; } ------ module main; import lib; getFoo(); // Allowed? takeFoo(getFoo()); // Allowed? Bar b; // Allowed? takeFoo(b.f); // Allowed? b.f = getFoo(); // Allowed? // Allowed? If so, can you *do* anything with x? auto x = getFoo(); ====================
Jan 24 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2012 01:59 AM, Peter Alexander wrote:
 On Wednesday, 25 January 2012 at 00:08:25 UTC, Timon Gehr wrote:
 Accessibility-raising aliases are trivially safe, because the alias
 declaration must have access to the aliased symbol.

You are probably right about not introducing holes, but I can imagine this getting tricky, and perhaps confusing in some cases. Here are some off the top of my head. module A; private class Foo {} public alias Foo Bar; In other modules that import A: Bar b = new typeof(b)(); // typeof(b) is Foo. Is this allowed? T foo(T)(T x) { return new T(); } Bar b; b = foo(b); // T is deduced to Foo, should this work? Bar b = new Bar(); mixin("b = new " ~ typeof(b).stringof ~ "();"); // This fails, the string is "Foo" Just thinking about this has made me change my position. Accessibility raising aliases should not be allowed. It's a minefield.

That is a valid counter-argument. While I am sure these issues could be sorted out, it would probably amount to over-engineering. This is basically the only useful use case worth considering: private template Tmpl(T){...} public alias Tmpl!int foo; Tmpl and Tmpl!int are two _distinct symbols_, and there is no dedicated syntax to make just one of them accessible. Therefore, this use case could be allowed as a special case: Explicit use of Tmpl from another module would be forbidden, but the instance Tmpl!int would be public under the name foo. (While explicitly instantiating Tmpl!int would fail, because Tmpl is not accessible (or ideally not visible).) There would be no public/private aliasing, and therefore all the issues you mentioned would not exist in this case.
Jan 24 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:jfnlpu$k0p$1 digitalmars.com...
 On 01/25/2012 01:59 AM, Peter Alexander wrote:
 On Wednesday, 25 January 2012 at 00:08:25 UTC, Timon Gehr wrote:
 Accessibility-raising aliases are trivially safe, because the alias
 declaration must have access to the aliased symbol.

You are probably right about not introducing holes, but I can imagine this getting tricky, and perhaps confusing in some cases. Here are some off the top of my head. module A; private class Foo {} public alias Foo Bar; In other modules that import A: Bar b = new typeof(b)(); // typeof(b) is Foo. Is this allowed? T foo(T)(T x) { return new T(); } Bar b; b = foo(b); // T is deduced to Foo, should this work? Bar b = new Bar(); mixin("b = new " ~ typeof(b).stringof ~ "();"); // This fails, the string is "Foo" Just thinking about this has made me change my position. Accessibility raising aliases should not be allowed. It's a minefield.

That is a valid counter-argument. While I am sure these issues could be sorted out, it would probably amount to over-engineering. This is basically the only useful use case worth considering: private template Tmpl(T){...} public alias Tmpl!int foo; Tmpl and Tmpl!int are two _distinct symbols_, and there is no dedicated syntax to make just one of them accessible. Therefore, this use case could be allowed as a special case: Explicit use of Tmpl from another module would be forbidden, but the instance Tmpl!int would be public under the name foo. (While explicitly instantiating Tmpl!int would fail, because Tmpl is not accessible (or ideally not visible).) There would be no public/private aliasing, and therefore all the issues you mentioned would not exist in this case.

There's no need for special cases. Just don't go de-aliasing symbols. That takes care of everything.
Jan 24 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2012 03:56 AM, Nick Sabalausky wrote:
 "Timon Gehr"<timon.gehr gmx.ch>  wrote in message
 news:jfnlpu$k0p$1 digitalmars.com...
 On 01/25/2012 01:59 AM, Peter Alexander wrote:
 On Wednesday, 25 January 2012 at 00:08:25 UTC, Timon Gehr wrote:
 Accessibility-raising aliases are trivially safe, because the alias
 declaration must have access to the aliased symbol.

You are probably right about not introducing holes, but I can imagine this getting tricky, and perhaps confusing in some cases. Here are some off the top of my head. module A; private class Foo {} public alias Foo Bar; In other modules that import A: Bar b = new typeof(b)(); // typeof(b) is Foo. Is this allowed? T foo(T)(T x) { return new T(); } Bar b; b = foo(b); // T is deduced to Foo, should this work? Bar b = new Bar(); mixin("b = new " ~ typeof(b).stringof ~ "();"); // This fails, the string is "Foo" Just thinking about this has made me change my position. Accessibility raising aliases should not be allowed. It's a minefield.

That is a valid counter-argument. While I am sure these issues could be sorted out, it would probably amount to over-engineering. This is basically the only useful use case worth considering: private template Tmpl(T){...} public alias Tmpl!int foo; Tmpl and Tmpl!int are two _distinct symbols_, and there is no dedicated syntax to make just one of them accessible. Therefore, this use case could be allowed as a special case: Explicit use of Tmpl from another module would be forbidden, but the instance Tmpl!int would be public under the name foo. (While explicitly instantiating Tmpl!int would fail, because Tmpl is not accessible (or ideally not visible).) There would be no public/private aliasing, and therefore all the issues you mentioned would not exist in this case.

There's no need for special cases. Just don't go de-aliasing symbols. That takes care of everything.

It does not. private class A{ static A factory(); } public alias A B; What is typeof(B.factory()) ?
Jan 24 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:jfnsne$10re$1 digitalmars.com...
 On 01/25/2012 03:56 AM, Nick Sabalausky wrote:
 There's no need for special cases. Just don't go de-aliasing symbols. 
 That
 takes care of everything.

It does not. private class A{ static A factory(); } public alias A B; What is typeof(B.factory()) ?

That's not a problem that's specific to alias. It's symptomatic of a more general access issue (instances of private types exposed in a public interface) that is *not* solved by prohibiting access-expanding aliases: private class A{ static A factory(); } public class B{ A foo() { return A.factory(); } } In another module: typeof((new B()).foo()) // What should happen? If "public alias A B" must be banned due to tough accessibility questions, then so must "class B". Point is, it's not an issue specific to alias.
Jan 24 2012
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jfo1i0$18rq$1 digitalmars.com...
 "Timon Gehr" <timon.gehr gmx.ch> wrote in message 
 news:jfnsne$10re$1 digitalmars.com...
 On 01/25/2012 03:56 AM, Nick Sabalausky wrote:
 There's no need for special cases. Just don't go de-aliasing symbols. 
 That
 takes care of everything.

It does not. private class A{ static A factory(); } public alias A B; What is typeof(B.factory()) ?

That's not a problem that's specific to alias. It's symptomatic of a more general access issue (instances of private types exposed in a public interface) that is *not* solved by prohibiting access-expanding aliases: private class A{ static A factory(); } public class B{ A foo() { return A.factory(); } } In another module: typeof((new B()).foo()) // What should happen? If "public alias A B" must be banned due to tough accessibility questions, then so must "class B". Point is, it's not an issue specific to alias.

Of course, my position isn't purely defensive. Here's why access-expanding aliases cannot be prohibited: private struct DirtyFooImpl(int i){} template Foo { alias DirtyFooImpl!5 Foo; } That's a simplistic example of very common, very useful idiom. Note that there's no way to do that without access-expanding aliases. If access-expanding aliases are banned, then this idiom must go away too. Then, a big chunk of my Goldie project and no doubt many other projects suddenly break, and the only way around it is to publically expose things that are *not supposed to be exposed*, and congrats, now we've just stepped back in time to pre-encapsulation-enforcement days.
Jan 24 2012
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <ludwig informatik.uni-luebeck.de> writes:
Another example would be synchronized classes:

synchronized class X {
	public alias f g;
	private void f(){}
}

Now g() would be a public method that is not protected by the class' 
mutex. This case would have to be explicitly forbidden.
Jan 25 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Sönke Ludwig" <ludwig informatik.uni-luebeck.de> wrote in message 
news:jfoh1s$25ce$1 digitalmars.com...
 Another example would be synchronized classes:

 synchronized class X {
 public alias f g;
 private void f(){}
 }

 Now g() would be a public method that is not protected by the class' 
 mutex. This case would have to be explicitly forbidden.

Or just cause f to be protected by the class's mutex.
Jan 25 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jfojur$2a7l$1 digitalmars.com...
 "Sönke Ludwig" <ludwig informatik.uni-luebeck.de> wrote in message 
 news:jfoh1s$25ce$1 digitalmars.com...
 Another example would be synchronized classes:

 synchronized class X {
 public alias f g;
 private void f(){}
 }

 Now g() would be a public method that is not protected by the class' 
 mutex. This case would have to be explicitly forbidden.

Or just cause f to be protected by the class's mutex.

After all, if you're making a public alias of f, then you obviously *do* want that function to be public-accessible, just not through the *name* "f".
Jan 25 2012
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <ludwig informatik.uni-luebeck.de> writes:
Am 25.01.2012 11:02, schrieb Nick Sabalausky:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jfojur$2a7l$1 digitalmars.com...
 "Sönke Ludwig"<ludwig informatik.uni-luebeck.de>  wrote in message
 news:jfoh1s$25ce$1 digitalmars.com...
 Another example would be synchronized classes:

 synchronized class X {
 public alias f g;
 private void f(){}
 }

 Now g() would be a public method that is not protected by the class'
 mutex. This case would have to be explicitly forbidden.

Or just cause f to be protected by the class's mutex.

After all, if you're making a public alias of f, then you obviously *do* want that function to be public-accessible, just not through the *name* "f".

...although it would be a bit awkward to have the original function change just because it is aliased somewhere (a bit like Schrödinger's cat). But actually I realize that there are far worse things concerning shared/synchronized + classes, so my example maybe is not really specific to 'alias' (e.g. I'm not sure what happens now if you make a delegate of f()...)
Jan 25 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:bfhygfbdlubuwelaqfws dfeed.kimsufi.thecybershadow.net...
 For example, one could argue that it's also obvious that an alias should 
 behave exactly the same as the thing it aliases. Allowing aliases to 
 change protection would break that.

FWIW, If someone were to argue that, my response would be something like: 1. If you wanted it *exactly* the same, you wouldn't have aliased it at all. So naturally, that "exactly" is subject to reasonable exceptions. 2. Protection levels apply to symbols, not the construct or data the symbol refers to. 3. (Just reiterating I guess:) Protection levels are not, should not, and cannot realistically be transitive.
 For the record, I agree that the answer should be "yes", but it's

Jan 24 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 24 January 2012 at 22:26:37 UTC, Nick Sabalausky 
wrote:
 This whole issue is literally *NO* different from "Should a 
 public pointer/reference be allowed to point to private data?" 
 or "Should a public function be allowed to expose a private 
 one?" The answer is: "Obviously yes".

Things can be obvious in different ways. For example, one could argue that it's also obvious that an alias should behave exactly the same as the thing it aliases. Allowing aliases to change protection would break that. For the record, I agree that the answer should be "yes", but it's not a decision that should be made rashly. If we aren't careful, we could introduce a hole in the protection system in a non-obvious way. C++'s protection system has a non-obvious hole: http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html Again, I agree, but what's obvious isn't always true, so it needs to be considered in depth.
Jan 24 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 25 January 2012 at 00:08:25 UTC, Timon Gehr wrote:
 Accessibility-raising aliases are trivially safe, because the 
 alias declaration must have access to the aliased symbol.

You are probably right about not introducing holes, but I can imagine this getting tricky, and perhaps confusing in some cases. Here are some off the top of my head. module A; private class Foo {} public alias Foo Bar; In other modules that import A: Bar b = new typeof(b)(); // typeof(b) is Foo. Is this allowed? T foo(T)(T x) { return new T(); } Bar b; b = foo(b); // T is deduced to Foo, should this work? Bar b = new Bar(); mixin("b = new " ~ typeof(b).stringof ~ "();"); // This fails, the string is "Foo" Just thinking about this has made me change my position. Accessibility raising aliases should not be allowed. It's a minefield.
Jan 24 2012
prev sibling next sibling parent reply equinox atw.hu writes:
Hi,

I have been thinking . Would not C and C++ backend would make DMD more  =

versatile?
D language could be used in many platforms easily.
D language could be used in .net and elsewhere.
It could be compiled with other language that are also translated into  =

C/C++.

Regards

M=E1rton Papp
Jan 25 2012
parent "Nick Sabalausky" <a a.a> writes:
<equinox atw.hu> wrote in message news:op.v8mxx6s9xa30qa marton-pc...
Hi,

I have been thinking . Would not C and C++ backend would make DMD more 
versatile?
D language could be used in many platforms easily.
D language could be used in .net and elsewhere.
It could be compiled with other language that are also translated into 
C/C++.

I think LDC can do that...At least in theory anyway, since LLVM has a C backend.
Jan 25 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Wednesday, 25 January 2012 at 12:03:15 UTC, Nick Sabalausky 
wrote:
 <equinox atw.hu> wrote in message 
 news:op.v8mxx6s9xa30qa marton-pc...
Hi,

I have been thinking . Would not C and C++ backend would make 
DMD more versatile?
D language could be used in many platforms easily.
D language could be used in .net and elsewhere.
It could be compiled with other language that are also 
translated into C/C++.

I think LDC can do that...At least in theory anyway, since LLVM has a C backend.

It does, but they tell you not to use it. Make of that what you will.
Jan 25 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 25 Jan 2012 05:26:20 -0500, <equinox atw.hu> wrote:

 Hi,

 I have been thinking . Would not C and C++ backend would make DMD more  
 versatile?
 D language could be used in many platforms easily.
 D language could be used in .net and elsewhere.
 It could be compiled with other language that are also translated into  
 C/C++.

IIRC, Walter is (slowly) working on that. -Steve
Jan 25 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Wed, Jan 25, 2012 at 4:26 AM,  <equinox atw.hu> wrote:
 Hi,

 I have been thinking . Would not C and C++ backend would make DMD more
 versatile?
 D language could be used in many platforms easily.
 D language could be used in .net and elsewhere.
 It could be compiled with other language that are also translated into
 C/C++.

As far as platform support goes, GDC *should* be able to target pretty much any platform GCC can currently target. There are probably some platform-specific issues at this point; one example would be that you have to disable the section-anchors optimization to get D running on ARM. There are also some fun things like Fibers not working because the getcontext/setcontext/makecontext functions in glibc are just stubs on ARM, but Iain has done an excellent job of adding GCC-specific version blocks to Druntime that replace most of the platform-specific code with pre-written GCC intrinsics. I know Daniel Green had some difficulty getting a toolchain that supports TLS on Windows, hopefully he can chime in on whether that's just Windows or will be an issue on other platforms as well.
Jan 25 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 The issue is not with aliases, accessability already has a natural grey
 area:

 ====================
 module lib;

 private struct Foo {}

 // Should any of these be allowed?
 public Foo getFoo() { return Foo(); }
 public void takeFoo(Foo f) {}
 struct Bar
 {
     Foo f;
 }

 ------

 module main;
 import lib;

 getFoo();  // Allowed?

 takeFoo(getFoo());  // Allowed?

 Bar b;  // Allowed?

 takeFoo(b.f);   // Allowed?

 b.f = getFoo();   // Allowed?

 // Allowed? If so, can you *do* anything with x?
 auto x = getFoo();

 ====================

Thus all of the above are allowed and you can do with x what Foo allows you to (aggregates default to public protection).
Jan 26 2012