Thread overview
Thoughts about private aliases now working
Feb 01, 2012
Robert Clipsham
Feb 02, 2012
Vladimir Panteleev
Feb 02, 2012
Martin Nowak
Feb 02, 2012
Marco Leise
Feb 02, 2012
Martin Nowak
Feb 02, 2012
Jacob Carlborg
February 01, 2012
Hi all,

I had to skip dmd 2.057 due to various bugs, so in the hopes that I'll be able to use my codebase with 2.058 I'm testing it early. Due to some fixes with private imports, some code I was previously using no longer works. It looks a little like this:

a.d
----
private alias string[string] SS;
mixin template Func()
{
    SS someFunc(SS s)
    {
        return s;
    }
}
----

b.d
----
import a;
mixin Func;
----

Now that private aliases work, this errors as expected (SS shouldn't be visible in b.d). What this does mean however is that I have to do one of:

 * Type out the type in full in Func (I'm not actually using string[string] in my code, it's a rather longer named type)
 * Make the alias public so it's available to all modules that import Func.

As it's an implementation detail, I'd rather not have it appear in user code, which rules out the latter, and typing out the full type makes a simple declaration use up several lines (or one obscenely long line!)

Are there any other options I'm missing? Is there some way to make the alias visible within the mixin but not elsewhere?

Thanks,

-- 
Robert
http://octarineparrot.com/
February 02, 2012
On Wednesday, 1 February 2012 at 23:14:47 UTC, Robert Clipsham wrote:
> Are there any other options I'm missing?

How about this:

> a.d
> ----
> private alias string[string] SS;
> mixin template Func()
> {

     private alias a.SS SS;

>    SS someFunc(SS s)
>    {
>        return s;
>    }
> }

( Amusing that the solution to a problem regarding private aliases would be more private aliases :) )
February 02, 2012
On Thu, 02 Feb 2012 01:55:11 +0100, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Wednesday, 1 February 2012 at 23:14:47 UTC, Robert Clipsham wrote:
>> Are there any other options I'm missing?
>
You need to put it in the mixin as you do with imports.

mixin template Func()
{
    private alias string[string] SS;
    SS someFunc(SS s)
    {
        return s;
    }
}

> How about this:
>
>> a.d
>> ----
>> private alias string[string] SS;
>> mixin template Func()
>> {
>
>       private alias a.SS SS;
You are still accessing a.SS from b so this won't work. It's a compiler bug and is fixed here
https://github.com/D-Programming-Language/dmd/pull/669.
February 02, 2012
Am 02.02.2012, 02:14 Uhr, schrieb Martin Nowak <dawg@dawgfoto.de>:

> On Thu, 02 Feb 2012 01:55:11 +0100, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>
>> On Wednesday, 1 February 2012 at 23:14:47 UTC, Robert Clipsham wrote:
>>> Are there any other options I'm missing?
>>
> You need to put it in the mixin as you do with imports.
>
> mixin template Func()
> {
>      private alias string[string] SS;
>      SS someFunc(SS s)
>      {
>          return s;
>      }
> }
>
>> How about this:
>>
>>> a.d
>>> ----
>>> private alias string[string] SS;
>>> mixin template Func()
>>> {
>>
>>       private alias a.SS SS;
> You are still accessing a.SS from b so this won't work. It's a compiler bug and is fixed here
> https://github.com/D-Programming-Language/dmd/pull/669.

I thought mixin templates were _supposed_ to run in the scope of the call site. Doesn't this mixin with the mixin blur the line and make the language less consistent/more confusing?
February 02, 2012
On 2012-02-02 02:14, Martin Nowak wrote:
> On Thu, 02 Feb 2012 01:55:11 +0100, Vladimir Panteleev
> <vladimir@thecybershadow.net> wrote:
>
>> On Wednesday, 1 February 2012 at 23:14:47 UTC, Robert Clipsham wrote:
>>> Are there any other options I'm missing?
>>
> You need to put it in the mixin as you do with imports.
>
> mixin template Func()
> {
> private alias string[string] SS;
> SS someFunc(SS s)
> {
> return s;
> }
> }

If you don't want to declare the alias in the mixin another idea would be to declare it in a new module and import that one in the mixin.

-- 
/Jacob Carlborg
February 02, 2012
> I thought mixin templates were _supposed_ to run in the scope of the call site. Doesn't this mixin with the mixin blur the line and make the language less consistent/more confusing?

They are. And the mixin body is valid in the scope of b.