View mode: basic / threaded / horizontal-split · Log in · Help
January 25, 2012
Re: public aliases to private/package symbols
"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.
January 25, 2012
Re: public aliases to private/package symbols
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()) ?
January 25, 2012
Re: public aliases to private/package symbols
"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.
January 25, 2012
Re: public aliases to private/package symbols
"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.
January 25, 2012
Re: public aliases to private/package symbols
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.
January 25, 2012
Re: public aliases to private/package symbols
"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.
January 25, 2012
Re: public aliases to private/package symbols
"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".
January 25, 2012
C/C++ backend for DMD?
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árton Papp
January 25, 2012
Re: public aliases to private/package symbols
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()...)
January 25, 2012
Re: C/C++ backend for DMD?
<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.
1 2 3
Top | Discussion index | About this forum | D home