January 25, 2012
"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
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
"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
"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
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
"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
"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
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
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
<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.