I have ctfe generated code which requires generating import statements so symbols can be looked up(avoiding the need to have to manually import modules).

1. Allow identical import statements not throw an error.
import std.conv : to;
import std.conv : to;

throws error

Error	1	Error: alias main.to conflicts with alias main.to at main.d(5)

such errors make it difficult to write generated code with weak state information(since ctfe's can store global state data.

2. Allow if an isImported statement which checks if a symbol is imported. This can reduce unnecessary import statements.


I get around 1 by using a table to store the import statements, but, again, this only works inside the ctfe call since the table can't be global. Multiple code generation in the scope may produce the issue.

You can use scoped local imports and avoid necessity to track global state.

On Tuesday, 30 July 2013 at 10:36:15 UTC, Dicebot wrote:
> You can use scoped local imports and avoid necessity to track global state.

Huh? If I follow you, this won't work. I'm generating code so don't have the luxury to mess with the outer scope where the code is going.

mixin(code fragment)

user code

mixin(code fragment)

user code

if both code fragments have the same import statement then there is an error. The only way for them to be aware of that is to have a global state(well, relative to the scope they are in).

On Tuesday, 30 July 2013 at 11:01:07 UTC, JS wrote:
> On Tuesday, 30 July 2013 at 10:36:15 UTC, Dicebot wrote:
>> You can use scoped local imports and avoid necessity to track global state.
>
> Huh? If I follow you, this won't work. I'm generating code so don't have the luxury to mess with the outer scope where the code is going.
>
> mixin(code fragment)
>
> user code
>
> mixin(code fragment)
>
> user code
>
> if both code fragments have the same import statement then there is an error. The only way for them to be aware of that is to have a global state(well, relative to the scope they are in).

Don't have imports generated in two different mixins in same scope. Either move each mixin into own scope, or move import generation code into separate mixin that get called once per scope. (example of vibe.d using latter: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/rest.d#L245)

On Tuesday, 30 July 2013 at 11:19:37 UTC, Dicebot wrote:
> On Tuesday, 30 July 2013 at 11:01:07 UTC, JS wrote:
>> On Tuesday, 30 July 2013 at 10:36:15 UTC, Dicebot wrote:
>>> You can use scoped local imports and avoid necessity to track global state.
>>
>> Huh? If I follow you, this won't work. I'm generating code so don't have the luxury to mess with the outer scope where the code is going.
>>
>> mixin(code fragment)
>>
>> user code
>>
>> mixin(code fragment)
>>
>> user code
>>
>> if both code fragments have the same import statement then there is an error. The only way for them to be aware of that is to have a global state(well, relative to the scope they are in).
>
> Don't have imports generated in two different mixins in same scope. Either move each mixin into own scope, or move import generation code into separate mixin that get called once per scope. (example of vibe.d using latter: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/rest.d#L245)

This can't be done. I am using mixins to generate interface code,
class code, etc....

There is only one scope to them. The imports can't be brought out
because they are generated directly from the mixin data passed.

e.g.,

class A
{
    mixin(Property("name", string));
    mixin(Property("x", iObject));
}

iObject potentially requires an import, so I import it... now if
I add


    mixin(Property("y", iObject));

then I'll have two iObjects imported... which will error and
fail, even though there is no big deal about it.

On Tuesday, 30 July 2013 at 11:39:59 UTC, JS wrote:
> class A
> {
>     mixin(Property("name", string));
>     mixin(Property("x", iObject));
> }
>
> iObject potentially requires an import, so I import it... now if
> I add
>
>
>     mixin(Property("y", iObject));
>
> then I'll have two iObjects imported... which will error and
> fail, even though there is no big deal about it.

class A
{
    alias fields = TypeTuple!("name", string, "x", iObject);
    mixin(generateImports!fields);
    mixin(generateProperties!fields);!
}

JS:

> I have ctfe generated code which requires generating import statements so symbols can be looked up(avoiding the need to have to manually import modules).
>
> 1. Allow identical import statements not throw an error.
> import std.conv : to;
> import std.conv : to;
>
> throws error
>
> Error	1	Error: alias main.to conflicts with alias main.to at main.d(5)
>
> such errors make it difficult to write generated code with weak state information(since ctfe's can store global state data.

That's untidy. Such things later bite your rump.

Bye,
bearophile

"JS" <js.mdnq@gmail.com> wrote in message news:ndlhucgwihfzjsxgihhr@forum.dlang.org...
> import std.conv : to;
> import std.conv : to;
>
> throws error
>
> Error 1 Error: alias main.to conflicts with alias main.to at main.d(5)

Please file a bug report: http://d.puremagic.com/issues/

On Tuesday, 30 July 2013 at 12:29:00 UTC, Daniel Murphy wrote:
> Please file a bug report: http://d.puremagic.com/issues/

I don't think it is a bug, enhancement request for error message at most.

2013/7/30 Dicebot <public@dicebot.lv>

> On Tuesday, 30 July 2013 at 12:29:00 UTC, Daniel Murphy wrote:
>
>> Please file a bug report: http://d.puremagic.com/issues/
>>
>
> I don't think it is a bug, enhancement request for error message at most.
>

Currently selective import *implicitly* creates alias declaration for each picked up names, and two equivalent selective import will make two alias declarations implicitly, then they conflict each other.

import std.conv : to;
import std.conv : to;

is mostly same as:

import std.conv;
alias to = std.conv.to;
alias to = std.conv.to;  // conflict with the first alias

I think it's a not good compiler implementation detail and unnecessary
intrusive behavior.
Now I'm proposing to fix import mechanism in here.
https://github.com/D-Programming-Language/dmd/pull/2256

Kenji Hara