On 2/3/17 6:33 PM, Walter Bright wrote:
> Daniel, Dominikus: please consider writing an article about this.

That would be indeed very very useful. -- Andrei

On 2/3/17 5:00 PM, deadalnix wrote:
> On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote:
>> 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.
>
> That's obviously a self important lookup.

This. So much this.

On Saturday, 4 February 2017 at 14:57:59 UTC, Andrei Alexandrescu wrote:
> On 2/3/17 6:33 PM, Walter Bright wrote:
>> Daniel, Dominikus: please consider writing an article about this.
>
> That would be indeed very very useful. -- Andrei

Okay, I will. However I currently have some obligations which demand my full attention, I estimate having a first draft ready by next weekend.

Daniel

On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote:
> 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!
>> 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.
Thank you all that you like the idea.
I found myself using this idiom quite some time now in my libraries but only recently realized, that it is the reason why I didn't found DIP1005 too compelling - I just didn't need it because of my workaround.
So I thought I should share the idea - and Daniels extension makes it much easier to use. Have to update my libs with that :-)

But is this really worth an article?

On Monday, 6 February 2017 at 08:45:45 UTC, Dominikus Dittes Scherkl wrote:

> But is this really worth an article?

IMO, as something targeted at non-D users, yes. A brief overview of D's module system, a description of the problem & how the DIP was brought up to address it, how the DIP was made irrelevant by the usage of features every D programmer knows by so many failed to realize could be used in this way... lots of meat for a post there.

I'd be happy to publish something like that on the D Blog.

On Monday, 6 February 2017 at 09:00:43 UTC, Mike Parker wrote:
> On Monday, 6 February 2017 at 08:45:45 UTC, Dominikus Dittes Scherkl wrote:
>
>> But is this really worth an article?
>
> IMO, as something targeted at non-D users, yes.
Oh yeah? For bragging about how D uses modules and doesn't need global imports at all?
This is not my style and I didn't feel that not needing global imports is something to brag about - they are useful as an overview.
But with this new idiom .di-files are even more useless now - or really need to declare all the local imports to replace the lost overview.

> A brief overview of D's module system, a description of the
> problem & how the DIP was brought up to address it,
But I'm not an expert for this. Especially I was not aware of any problem and even didn't liked the DIP.

> how the DIP was made irrelevant by the usage of features
> every D programmer knows but so many failed to realize could
> be used in this way...
Ok, this is the most interesting part. This is what having an idea is all about. Find new ways to put the things already there together. But hard to describe.
Maybe I'll give it a try.

On 2/6/2017 12:45 AM, Dominikus Dittes Scherkl wrote:
> But is this really worth an article?

It's ideally suited for an article. It's easy to grasp, and enables a very interesting idiom.

On Monday, 6 February 2017 at 09:39:25 UTC, Dominikus Dittes Scherkl wrote:
> On Monday, 6 February 2017 at 09:00:43 UTC, Mike Parker wrote:
>> On Monday, 6 February 2017 at 08:45:45 UTC, Dominikus Dittes Scherkl wrote:
>>
>>> But is this really worth an article?
>>
>> IMO, as something targeted at non-D users, yes.
> Oh yeah? For bragging about how D uses modules and doesn't need global imports at all?

No, that's not quite my intent. There's an interesting story here beyond the feature itself that I believe makes for a good blog post. The majority of visitors to the blog are not D users and aren't going to be familiar with the details (like the different ways a module can be imported), so such an article needs to keep them in mind.

On Monday, 6 February 2017 at 11:03:32 UTC, Walter Bright wrote:
> On 2/6/2017 12:45 AM, Dominikus Dittes Scherkl wrote:
>> But is this really worth an article?
>
> It's ideally suited for an article. It's easy to grasp, and enables a very interesting idiom.

I personally think the idiom is neato and think it'd be a neat article! It could potentially inspire wonder in some non-D-users about the limitless possibilities of the language... Or scare some away. :V The idiom would pretty bizarre for newcomers lol.

On Friday, 3 February 2017 at 15:41:56 UTC, 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;
> }

I don't understand why we can't use a template like:

auto fun_time(SysTime)(SysTime tm)
{
    import std.datetime;
    static assert (is(SysTime == std.datetime.SysTime));
    return tm;
}

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

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

I think I missed something.