On Wed, 22 Jun 2011 14:52:52 +0300, Peter Alexander <peter.alexander.au@gmail.com> wrote:

> // module A
> private class Foo;
> public alias Foo[] Foos;
>
> // module B
> void main()
> {
>      Foos fs; // Legal? Seems so.
>      Foo f = fs[0]; // Clearly can't use Foo here, it's private.
>      auto f2 = fs[0]; // Legal?
>      fs[0].memFun(); // Legal?
> }

I don't think this is a big problem because both Foo and Foos are defined/aliased by the library developer.
Similar reasoning would be applied to many other cases where a library developer allows/disallows/does something that ends up with errors on the user side, intended or not, competent or not.

> Of course, the same problems arise if you alias something like Array!Foo.

Well, as long as Foo is private.

On Nick's example:

private class Foo {}
public bar(Foo f) {}

Just like the Foo/Foos example this is also entirely lib developers fault, what is he thinking, and why is this enough? He could after all do something like this and be done with it.

static this() {
  unleash_hell();
}

> So the difference between class aliasing and functional composition is that class aliasing does not completely encapsulate the class, while the function does. Function composition is more analogous to structural composition.
>
> In my opinion, it should be illegal to publicly alias a private type (or any derivative type) because it introduces too many issues, as I have demonstrated above.

The template example alone is enough of a reason to have this IMO.

On 22/06/11 2:19 PM, Nick Sabalausky wrote:
> In your example, the user needs to be able to use the Foo symbol in order to
> get full use out of Foos. However, in my example, the user does *not* need
> to use the Foo symbol in order to get full use out of Bar. They can just use
> Bar in place of Foo. The "Foo" symbol is a necessary part of Foos's
> interface, but it is *not* a necessary part Bar's interface.

They don't *need* the Foo symbol:

// module A
private class Foo;
public alias Foo[] Foos;
Foos getFoos();

// module B
import A;
void main()
{
    Foos foos = getFoos();
    foos[0].someFunc();
    auto f = foos[0];
}


Here, module B hasn't used the Foo symbol, but it's as if Foo isn't private at all. I don't know about you, but this feel really wrong to me.

"Peter Alexander" <peter.alexander.au@gmail.com> wrote in message news:itsqov$1mnt$1@digitalmars.com...
> On 22/06/11 2:19 PM, Nick Sabalausky wrote:
>> In your example, the user needs to be able to use the Foo symbol in order
>> to
>> get full use out of Foos. However, in my example, the user does *not*
>> need
>> to use the Foo symbol in order to get full use out of Bar. They can just
>> use
>> Bar in place of Foo. The "Foo" symbol is a necessary part of Foos's
>> interface, but it is *not* a necessary part Bar's interface.
>
> They don't *need* the Foo symbol:
>
> // module A
> private class Foo;
> public alias Foo[] Foos;
> Foos getFoos();
>
> // module B
> import A;
> void main()
> {
>     Foos foos = getFoos();
>     foos[0].someFunc();
>     auto f = foos[0];
> }
>
>
> Here, module B hasn't used the Foo symbol, but it's as if Foo isn't private at all. I don't know about you, but this feel really wrong to me.
>

Perhaps. I could probably be persuaded either way.

But again, I don't see that as being relevent to:

private class Foo;
public alias Foo Bar;