On Sat, 24 Dec 2016 17:45:35 +0000, Stefan Koch wrote:
> I just read over the dip, and it is a giant wall of text.
> I cannot really make heads or tails of it.
> Maybe you could write the advantages you hit at in short bullet-point
> form ?

We add the syntax:

with (import foo, bar, baz)
SingleDeclaration

* If you're reading it as source code, you have, usually, 1-3 modules to look in for related definitions, instead of lots (plain imports) or one (static / selective imports).

* These modules are listed one line up from the declaration (as with static imports, unlike selective imports).

* It doesn't look quite as cluttered as static imports.

* It saves a little typing compared to static imports when you use the same import twice in one declaration.

* If you need to move this declaration to another module, you don't have to worry about imports (provided you assiduously avoid global imports). You still have to worry about everything the declaration references from the module it was previously defined in.

* The compiler can delay importing the module until you use the declaration it's attached to.

* It might be slightly easier to implement in DMD than lazy static / selective imports.



We extend that syntax:

with (import foo)
with (import bar, baz)
{
  // multiple declarations
  // possibly other with-import blocks
}

* You have even less typing if you reuse the same import in a lot of declarations.

* The compiler can still delay importing the module until you use the declaration it's attached to.

* You get to have a fun search through the entire module to try to find which modules are imported when reading a declaration, instead of looking up one line (first pass on the syntax), looking at the symbol being used (static imports), or looking at the top of the file (status quo or selective imports).

* That also applies when you try to move a declaration to another module.

On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu wrote:
>> A compiler enhancement can do this _without_ a language change.
>
> The language addition has additional benefits as described by DIP1005. -- Andrei

Yes, question is, are these specific benefits worth adding a language change ?

Right now you got :

A/ No language change, get X.
B/ Language change, get X and Y.

It stand to reason that B should be evaluated on the benefit provided by Y, and Y only, rather than X and Y, as X can be provided without the language change.

On Saturday, 24 December 2016 at 19:16:40 UTC, Joakim wrote:
> Can we hold off on the performance discussion?  Walter says this DIP isn't hard to implement (https://github.com/dlang/DIPs/pull/51#issuecomment-269077790), so we will run some numbers and see what we get.  As you know, I too am skeptical of the benefit but Andrei has shown that import fanout has a non-negligible cost with his latest benchmark, and actual measurement will be the best way to decide.

The "problem" is that you'd be essentially measuring how inefficient the current DMD import management is rather than anything else.

When you push something on the user, you want to make sure it bring an actual benefit, not just allow to work around lousy existing implementation.

On 12/28/16 10:48 AM, deadalnix wrote:
> On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu wrote:
>>> A compiler enhancement can do this _without_ a language change.
>>
>> The language addition has additional benefits as described by DIP1005.
>> -- Andrei
>
> Yes, question is, are these specific benefits worth adding a language
> change ?
>
> Right now you got :
>
> A/ No language change, get X.
> B/ Language change, get X and Y.
>
> It stand to reason that B should be evaluated on the benefit provided by
> Y, and Y only, rather than X and Y, as X can be provided without the
> language change.

This is exactly what the DIP describes in detail. It consecrates sections to alternatives. Is anything missing? -- Andrei

On Wed, 28 Dec 2016 15:48:46 +0000, deadalnix wrote:

> On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu wrote:
>>> A compiler enhancement can do this _without_ a language change.
>>
>> The language addition has additional benefits as described by DIP1005. -- Andrei
> 
> Yes, question is, are these specific benefits worth adding a language change ?

And the associated detriments. Just imagine opening up phobos and seeing:

  // 1200 lines of code
  with (import foo)
  {
    // 300 lines of declarations...
    with (import bar)
    {
      // 250 lines of additional declarations...
    }
  }

All mixed in with structs and functions and conditional compilation, so you have a sea of curly braces to wade through and indentation is only a mild help.

On 12/28/16 9:47 PM, Chris Wright wrote:
> On Wed, 28 Dec 2016 15:48:46 +0000, deadalnix wrote:
>
>> On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu
>> wrote:
>>>> A compiler enhancement can do this _without_ a language change.
>>>
>>> The language addition has additional benefits as described by DIP1005.
>>> -- Andrei
>>
>> Yes, question is, are these specific benefits worth adding a language
>> change ?
>
> And the associated detriments. Just imagine opening up phobos and seeing:
>
>   // 1200 lines of code
>   with (import foo)
>   {
>     // 300 lines of declarations...
>     with (import bar)
>     {
>       // 250 lines of additional declarations...
>     }
>   }
>
> All mixed in with structs and functions and conditional compilation, so
> you have a sea of curly braces to wade through and indentation is only a
> mild help.

The D Standard Library will generally specify dependencies with declarations. If the point was that the feature can be misused or abused if one really tries, I agree. -- Andrei

On Wednesday, 28 December 2016 at 23:14:48 UTC, Andrei Alexandrescu wrote:
> On 12/28/16 10:48 AM, deadalnix wrote:
>> On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu wrote:
>>>> A compiler enhancement can do this _without_ a language change.
>>>
>>> The language addition has additional benefits as described by DIP1005.
>>> -- Andrei
>>
>> Yes, question is, are these specific benefits worth adding a language
>> change ?
>>
>> Right now you got :
>>
>> A/ No language change, get X.
>> B/ Language change, get X and Y.
>>
>> It stand to reason that B should be evaluated on the benefit provided by
>> Y, and Y only, rather than X and Y, as X can be provided without the
>> language change.
>
> This is exactly what the DIP describes in detail. It consecrates sections to alternatives. Is anything missing? -- Andrei

This was more a comment about the current discussion than the DIP. A lot of discussion effort was focused on performance, but most of it can be achieved without language change - as the DIP states.

I think the performance gain we are looking at here is marginal, and I don't expect people to change their code to get a marginal benefit, so I suggest the performance aspect of the change to be simply left aside.

So the question now is would the added expressivity of per declaration import be worth the language change. I have to admit I'm not convinced either way.

Finally, while I proposed a variation of the "with import" combo in the past, I'm now much more convinced that using the plain import syntax, without the ';' is better. I was afraid there was a syntax conflict, but it doesn't looks like there is one. This will not introduce a new syntax, but allow an existing one to be used in a new location. This is, IMO, much more valuable.

On Friday, 30 December 2016 at 18:11:54 UTC, deadalnix wrote:

> I think the performance gain we are looking at here is marginal, and I don't expect people to change their code to get a marginal benefit, so I suggest the performance aspect of the change to be simply left aside.

Yes, imports are (in most cases) not performance relevant!

> So the question now is would the added expressivity of per declaration import be worth the language change. I have to admit I'm not convinced either way.

Neither am I.

> Finally, while I proposed a variation of the "with import" combo in the past, I'm now much more convinced that using the plain import syntax, without the ';' is better. I was afraid there was a syntax conflict, but it doesn't looks like there is one. This will not introduce a new syntax, but allow an existing one to be used in a new location. This is, IMO, much more valuable.

I am still not sure what problem it is trying to solve :)

On Fri, 30 Dec 2016 18:18:12 +0000, Stefan Koch wrote:
> I am still not sure what problem it is trying to solve :)

* Performance improvements, primarily when a module imports another,
bulky module for optional functionality.
* Making it easier to locate where things are defined when reading code.
* Making it easier to move declarations between files.

On Friday, 30 December 2016 at 22:29:18 UTC, Chris Wright wrote:
> * Performance improvements, primarily when a module imports another,
> bulky module for optional functionality.
That is solved by selective imports.

> * Making it easier to locate where things are defined when reading code.

That is solved by selective imports.

> * Making it easier to move declarations between files.

That is solved by selective imports.

Inline imports are really just a addition retrive the the deprecated behavior of fullyQualifedNames which would implicitly import.