On Friday, 16 December 2016 at 00:53:14 UTC, Timothee Cour wrote:
> one more thing:
>
> we can simplify further (while still having formatted looking code) with
> !q{} instead of !() :
>
> ```
> // applies to next decl
> @deps!q{import std.algorithm;}
> void test1(){}
>
> // applies to a set of decls
> @deps!q{import std.stdio;}{
>   void test2(){}
>   void test3(){}
> }
>
> // applies to all following decls (':')
> @deps!q{import std.array;}:

q{} would suggest the argument is a string, right? Plus, why does deps have to be a template?

>
> // can specify other dependencies beyond imports and have arbitrary complex
> logic:
> @deps!q{
>   import std.range;
>   static int[100] data2;
>   version(linux){
>     enum data1=import("foo");//string import
>     pragma(lib, "curl");
>   }
> }:

This is unnecessarily powerful.

> void test4(){}
>
> // Can alias some dependencies:
> alias deps1=deps!q{import std.algorithm;};
>
> @deps1
> void test4(){}

I would prefer my @import alternative. If we make use of q{}, it would look fine too:

@import(q{std.file: File}) @import(q{std.range: isInputRange})
void foo(T)(File x) if (isInputRange!T);

> ```
>
>
>
> On Thu, Dec 15, 2016 at 3:46 PM, ArturG via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> [...]

On 12/15/2016 8:32 AM, Andrei Alexandrescu wrote:
> On 12/15/2016 11:11 AM, Walter Bright wrote:
>> On 12/15/2016 6:53 AM, Andrei Alexandrescu wrote:
>>> The document does specify the advantages and disadvantages of lazy
>>> imports, as follows:
>>>
>>> ===
>>> * Full lazy `import`s. Assume all `import`s are lazy without any
>>> change in the
>>> language. That would allow an idiom by which libraries use fully
>>> qualified names
>>> everywhere, and the `import`s would be effected only when names are
>>> looked up.
>>> This would allow scalability but not the dependency-carrying aspect.
>>> ===
>>
>> That would be a massive breaking change.
>
> This may be a misunderstanding. The idiom would be opt-in so existing behavior
> will be preserved (albeit it won't benefit of the improvements).

If existing behavior is preserved, how can it lazily parse the imports?

On 12/15/2016 1:48 PM, deadalnix wrote:
> On Thursday, 15 December 2016 at 16:11:56 UTC, Walter Bright wrote:
>> That would be a massive breaking change.
>
> SDC do parse the module only when an identifier resolution reach top level, and
> then populate the module's top level symbol table without running any semantic
> analysis on any of its symbols.

I have a hard time seeing in practice where one would ever find it not necessary to parse for symbols. Note that 'object' is implicitly imported, so just using 'size_t' means every top level import has to be parsed.


> Symbol are analyzed on demand when they are used.

I agree that is not breaking and actually is something I've planned to implement in dmd for a while.

On 12/15/2016 1:48 PM, deadalnix wrote:
> You may also want to look at https://www.youtube.com/watch?v=b_T-eCToX1I to see
> what clang's up to.

Thanks. I see they've done much that Zortech C++ did to be fast, as well as Warp and dmd.

dmd eliminates the need for lib and ar by building in the code for that, so object files do not have to be written then read. I've often thought that this should be done with the linker, too. I.e. have dmd generate an exe file directly.

On 12/15/2016 9:07 AM, Dominikus Dittes Scherkl wrote:
> So, I no longer propose to change nothing except the internal compiler behaviour.
> Now I propose to additionally change the .di-file generation to also add all
> local imports to the start of the declaration file, so that having this file
> gives ALL dependencies of the declared stuff.

That will subtly change the behavior of overloads across module lookups.

On Friday, 16 December 2016 at 07:15:51 UTC, Walter Bright wrote:
> On 12/15/2016 9:07 AM, Dominikus Dittes Scherkl wrote:
>> So, I no longer propose to change nothing except the internal compiler behaviour.
>> Now I propose to additionally change the .di-file generation to also add all
>> local imports to the start of the declaration file, so that having this file
>> gives ALL dependencies of the declared stuff.
>
> That will subtly change the behavior of overloads across module lookups.

Hm. Maybe if the .di-file would be used for code generation. But does that make sense? A .di-file is delivered together with an already compiled library to provide the sources of templates AND to show up all dependencies of the library, no? Both for the interested reader and the compiler. And the actual .di-files doesn't do that correct.

On Thursday, 15 December 2016 at 22:56:42 UTC, Dmitry Olshansky wrote:
> On 12/13/16 11:33 PM, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> On first it seems like an awesome idea. That solves ... but wait what? Thinking more  about the problem at hand - I fail to see what this DIP accomplishes that can't be done better today.
>
> 1. The benefit of placing import to each function is based on the untold assumption that we have:
> a) huge modules with many functions
> b) that constraints of these functions require different (large) modules
>
> The reality is far from this picture - if anything 99% of template constraints are dependent on std.range.primitives and std.traits with a bit of std.meta from time to time. So we'd have a boilerplate of
>
> auto foo(R)(R range)
> (import std.range.primitives)
> if(isInputRange!R){ ... }
>
> everywhere for no noticeable benefit - touch one of functions and you get full set of imports of these _small_ modules.
>
> 2. By itself the mechanism for delaying import even for constraint until the function is touched is moot as long as the module in question is huge and is not split in pieces. In other words:
>
> auto foo(R)(R range)
> (import std.range)
> if(isInputRange!R){ ... }
>
> Pulls in full std.range the moment foo is touched, compared to
>
> import std.range.primitives;
> ...
> auto foo(R)(R range)
> if(isInputRange!R){ ... }
>
> which is because it actually isolates the whole mess of complete std.range from the user of a template.
>
> All in all my practical response is split the modules at least in 2 parts: constraints + full functionality, then import the one with constraints at the top level. Works today and solves the practical issues unlike the proposal.
>
> ---
> Dmitry Olshansky

+1

I understand the motivation for the proposal but I think that good practice with package/module organisation renders the benefits marginal. The flipside of that is that introducing this new syntax reduces the pressure on people to organise their code sensibly.

Is it a feature I'd like to be able to use when I'm writing: yes

Is it a feature I actually want to see in D and in the D codebases I read daily: probably no, meh

Is it worth the time and effort of core developers and community reviewers, both now and as an ongoing feature-maintenance burden: absolutely not. I have no idea why this proposal is a priority right now.

On 12/15/2016 05:56 PM, Dmitry Olshansky wrote:
> On 12/13/16 11:33 PM, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> On first it seems like an awesome idea. That solves ... but wait what?
> Thinking more  about the problem at hand - I fail to see what this DIP
> accomplishes that can't be done better today.
[snip]

Thanks for this great feedback. I have improved the DIP to integrate it:

Commit: https://github.com/dlang/DIPs/pull/51/commits/8f86c5add037c2bfb519dbcd646d1946b0e96571

Current file: https://github.com/dlang/DIPs/pull/51/files

View: https://github.com/dlang/DIPs/blob/8f86c5add037c2bfb519dbcd646d1946b0e96571/DIPs/DIP1005.md



Andrei

On 12/16/2016 04:58 AM, John Colvin wrote:
> Is it worth the time and effort of core developers and community
> reviewers, both now and as an ongoing feature-maintenance burden:
> absolutely not. I have no idea why this proposal is a priority right now.

Walter and I wanted to have a positive example of a good DIP that is relatively simple, is noncontroversial, and marks a definite move forward.

We believe the feature's benefits are significant, obvious, and immediate. With this feature, any large project would be able to radically clarify and improve its dependency structure with only little refactoring work. I interpret the negative feedback as failings of the DIP to explain and argue matters appropriately, so I'm working hard on improving it. Please keep feedback coming.


Thanks,

Andrei

On 12/13/2016 05:33 PM, Andrei Alexandrescu wrote:
> Destroy.
>
> https://github.com/dlang/DIPs/pull/51/files

Major changes effected to the DIP, which affect it. In-depth discussion of lazy imports, a change in lookup rules, and a few minor things:

https://github.com/dlang/DIPs/blob/d228f48a12c1d976735412fd5b7543cb1febda7b/DIPs/DIP1005.md


Andrei