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
On Tuesday, January 24, 2012 18:58:45 Martin Nowak wrote:
> Should aliases be allowed to raise the accessibility of a symbol?
>
> http://d.puremagic.com/issues/show_bug.cgi?id=4533
Having an alias make a symbol more accessible makes no sense to me IMHO. If
you're talking about private -> public,
On 01/24/2012 07:52 PM, Jonathan M Davis wrote:
On Tuesday, January 24, 2012 18:58:45 Martin Nowak wrote:
Should aliases be allowed to raise the accessibility of a symbol?
http://d.puremagic.com/issues/show_bug.cgi?id=4533
Having an alias make a symbol more accessible makes no sense to me IMH
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.
Yes, because the module cannot transparently change the implementation
of the aliased types if the template that provided the basis is public.
(If you ignore error messages.) I think private->public aliases make
sense and should be allowed.
I mostly agree with Jonathan, but that's a good a
"Martin Nowak" wrote in message
news:mailman.782.1327427928.16222.digitalmar...@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.
"Nick Sabalausky" wrote in message
news:jfnag6$317n$1...@digitalmars.com...
> "Martin Nowak" wrote in message
> news:mailman.782.1327427928.16222.digitalmar...@puremagic.com...
>> Should aliases be allowed to raise the accessibility of a symbol?
>>
>> http://d.puremagic.com/issues/show_bug.cgi?
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".
Thin
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 privat
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 confus
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" 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
"Nick Sabalausky" wrote in message
news:jfojur$2a7l$1...@digitalmars.com...
> "Sönke Ludwig" 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() w
Am 25.01.2012 11:02, schrieb Nick Sabalausky:
"Nick Sabalausky" wrote in message
news:jfojur$2a7l$1...@digitalmars.com...
"Sönke Ludwig" wrote in message
news:jfoh1s$25ce$1...@digitalmars.com...
Another example would be synchronized classes:
synchronized class X {
public alias f g;
private v
"Peter Alexander" wrote in message
news:jzvidktaqmkptrooi...@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.
>
> Yo
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
"Timon Gehr" 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 th
On 01/25/2012 03:56 AM, Nick Sabalausky wrote:
"Timon Gehr" 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 al
"Timon Gehr" 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
"Nick Sabalausky" wrote in message
news:jfo1i0$18rq$1...@digitalmars.com...
> "Timon Gehr" 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
>>> ta
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;
21 matches
Mail list logo
