DIP 1005 provides new syntax to make it possible to avoid global imports.
Till now global imports are necessary if a function uses types declared in some imported module within it's declaration or definition (otherwise a local import will do).

But this can already be worked around with some nice trick:

import someModule.SomeType;

SomeType fun()
{
   ...
}

can be replaced by:

fun.ST fun()
{
   import someModule.SomeType;
   alias ST = SomeType;
   ...
}

The same strategy works with types used in parameters or constraints, of course.

Any thoughts?

On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote:
> DIP 1005 provides new syntax to make it possible to avoid global imports.
> Till now global imports are necessary if a function uses types declared
> in some imported module within it's declaration or definition (otherwise
> a local import will do).
>
> But this can already be worked around with some nice trick:
>
> import someModule.SomeType;
>
> SomeType fun()
> {
>    ...
> }
>
> can be replaced by:
>
> fun.ST fun()
> {
>    import someModule.SomeType;
>    alias ST = SomeType;
>    ...
> }
>
> The same strategy works with types used in parameters or constraints, of
> course.
>
> Any thoughts?

Needless syntax sugar:

struct Foo { int x; }

Foo func() {
	return Foo(9);	
}

typeof(func()) func2() {
	return func();	
}

void main() {
	assert(func2.x == 9);	
}

On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote:
> DIP 1005 provides new syntax to make it possible to avoid global imports.
> Any thoughts?

I like it!

template imp(string mod)
{
  mixin("import imp = " ~ mod ~ ";");
}

auto fun_time(imp!"std.datetime".SysTime tm)
{
  return tm;
}

void main()
{
  import std.stdio;
  import std.datetime;

  fun_time(Clock.currTime()).writeln;
}

On Friday, 3 February 2017 at 14:59:09 UTC, rikki cattermole wrote:
> On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote:
>> DIP 1005 provides new syntax to make it possible to avoid global imports.
>> But this can already be worked around with some nice trick:
>> Any thoughts?
>
> Needless syntax sugar:
?!?
What is syntactic sugar?
I did NOT propose any new syntax - my workaround already works with the current D language. In fact I think DIP1005 is syntactic sugar (maybe even "needless").

On Fri, 03 Feb 2017 14:43:01 +0000, Dominikus Dittes Scherkl wrote:
> fun.ST fun()
> {
>     import someModule.SomeType;
>     alias ST = SomeType;
>     ...
> }

What compiler version is this? I'm getting segfaults with both 2.072.2 and 2.073.0.

Reported as https://issues.dlang.org/show_bug.cgi?id=17140

On 2/3/17 10:41 AM, Daniel N wrote:
> On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote:
>> DIP 1005 provides new syntax to make it possible to avoid global imports.
>> Any thoughts?
>
> I like it!
>
> template imp(string mod)
> {
>   mixin("import imp = " ~ mod ~ ";");
> }
>
> auto fun_time(imp!"std.datetime".SysTime tm)
> {
>   return tm;
> }
>
> void main()
> {
>   import std.stdio;
>   import std.datetime;
>
>   fun_time(Clock.currTime()).writeln;
> }

Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it seems to be doing out of the box most of what we want with DIP1005 with no language change at all.

Congratulations!


Andrei

On 2/3/17 2:14 PM, Andrei Alexandrescu wrote:
> On 2/3/17 10:41 AM, Daniel N wrote:
>> On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl
>> wrote:
>>> DIP 1005 provides new syntax to make it possible to avoid global
>>> imports.
>>> Any thoughts?
>>
>> I like it!
>>
>> template imp(string mod)
>> {
>>   mixin("import imp = " ~ mod ~ ";");
>> }
>>
>> auto fun_time(imp!"std.datetime".SysTime tm)
>> {
>>   return tm;
>> }
>>
>> void main()
>> {
>>   import std.stdio;
>>   import std.datetime;
>>
>>   fun_time(Clock.currTime()).writeln;
>> }
>
> Wow. This is... brilliant. Thanks for the great idea. I ran a few tests
> and it seems to be doing out of the box most of what we want with
> DIP1005 with no language change at all.
>
> Congratulations!

I should also extend thanks to Dominik, who provided the initial idea and the inspiration for this one. -- Andrei

On Friday, 3 February 2017 at 19:14:16 UTC, Andrei Alexandrescu wrote:
>
> Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it seems to be doing out of the box most of what we want with DIP1005 with no language change at all.
>
> Congratulations!
>
>
> Andrei

Thank you very much. I was just going to mail you directly to make sure the idea wasn't lost in the forum flood, will be exciting to see some measurements using this idiom.

Daniel N

On Friday, 3 February 2017 at 20:04:22 UTC, Daniel Nielsen wrote:
> On Friday, 3 February 2017 at 19:14:16 UTC, Andrei Alexandrescu wrote:
>>
>> Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it seems to be doing out of the box most of what we want with DIP1005 with no language change at all.
>>
>> Congratulations!
>>
>>
>> Andrei
>

I just had to try one more thing. It never ceases to amaze me what is possible in D today.

template imp(string mod) { mixin("import imp = " ~ mod ~ ";"); }
auto fun_time(imp!"std.datetime".SysTime tm) { return tm; }

void main()
{
  with(imp!"std.datetime")
    static if(is(Clock))
      with(imp!"std.stdio")
        Clock.currTime.fun_time.writeln;
}

On 2/3/2017 11:14 AM, Andrei Alexandrescu wrote:
> On 2/3/17 10:41 AM, Daniel N wrote:
>> On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote:
>>> DIP 1005 provides new syntax to make it possible to avoid global imports.
>>> Any thoughts?
>>
>> I like it!
>>
>> template imp(string mod)
>> {
>>   mixin("import imp = " ~ mod ~ ";");
>> }
>>
>> auto fun_time(imp!"std.datetime".SysTime tm)
>> {
>>   return tm;
>> }
>>
>> void main()
>> {
>>   import std.stdio;
>>   import std.datetime;
>>
>>   fun_time(Clock.currTime()).writeln;
>> }
>
> Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it
> seems to be doing out of the box most of what we want with DIP1005 with no
> language change at all.
>
> Congratulations!

I agree, it's pretty dazz! We need to give this technique a memorable name (not an acronym). I thought "Voldemort Types" turned out rather well, whereas CTFE is klunky, UFCS is even worse. The absolute worst is C++ SFINAE.

Any ideas?

  Scherkl-Nielsen Lookup?

The perfect bikeshedding moment!

Daniel, Dominikus: please consider writing an article about this.