"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.

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()) ?

"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.

"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.

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.

"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.

"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".

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

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()...)

<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.