DIP10005: Dependency-Carrying Declarations is now available for community feedback

Mon Dec 19 21:33:22 PST 2016

what about using `lazy` instead of `with`:

`with(import foo)`
=>
`lazy(import foo)`

advantages:
* avoids confusion regarding usual scoping rules of `with` ;
* conveys that the import is indeed lazy

Furthermore (regardless of which keyword is used), what about allowing `:`
```
// case 1
lazy(import foo)
void fun(){}

// case 2
lazy(import foo) {
  void fun(){}
}

// case 3 : this is new
lazy(import foo):
void fun1(){}
void fun2(){}
```

advantages:

* same behavior as other constructs which don't introduce a scope:
```
// case 1, 2 3 are allowed:
version(A):
static if(true):
private:
void fun(){}
```

* avoids nesting when case 3 is used (compared to when using `{}`)

* I would argue that grouping lazy imports is actually a common case;
without case 3, the indentation will increase.

On Mon, Dec 19, 2016 at 8:56 PM, Timothee Cour <thelastmammoth at gmail.com>
wrote:

> Andrei: you can use blockquotes to make long lines wrap when quoting text:
>
> https://github.com/adam-p/markdown-here/wiki/Markdown-
> Here-Cheatsheet#blockquotes
>
> that way, we don't have to scroll everytime there's a quote, eg:
>
> replace:
> <tab>Such scaffolding is of course
> with:
> > Such scaffolding is of course
>
>
>
>
> On Mon, Dec 19, 2016 at 8:04 PM, Andrei Alexandrescu via Digitalmars-d <
> digitalmars-d at puremagic.com> wrote:
>
>> On 12/19/2016 01:47 AM, Joakim wrote:
>>
>>> Why do you care _so_ much about the module dependency graph?  To make
>>> this question concrete, let's look at an example, the std.array module
>>> you keep mentioning.
>>> This is what it looked like before Ilya scoped as
>>> many imports as he could:
>>>
>>> https://github.com/dlang/phobos/commit/3fcf723aa498b96de1653
>>> 61b5abb9d3450fdc069#diff-54cf8402b22024ae667d4048a5126f0e
>>>
>>> That was a mess, similar to opaque C/C++ code, 13 modules imported at
>>> module-scope were whittled down to 4.  You just made those more specific
>>> in a commit related to this DIP, by listing the actual symbols
>>> selectively imported from those four modules:
>>>
>>> https://github.com/dlang/phobos/commit/e064d5664f92c4b2f0866
>>> c08f6d0290ba66825ed#diff-54cf8402b22024ae667d4048a5126f0e
>>>
>>>
>>> If I'm looking at the template constraints for any particular function
>>> and see a couple symbols I don't recognize, I don't think it's a big
>>> deal to find the symbols in that list at the top.
>>>
>>
>> It actually is. Some symbols in e.g. std.range are used in constraints,
>> some others used in definitions; some in a UFCS manner. Some code runs
>> during compilation, with errors gagged (as in __traits(compiles)) or not
>> gagged. I don't know of an easy manual method to figure out who's who
>> (which makes Vladimir's idea of tooling it with brute force awesome and
>> scary at the same time).
>>
>> At any way, I don't see how I can use this tidbit to improve the DIP.
>> Anything I could add to it to make it more compelling?
>>
>> In other words, D already allows you to scope most imports.  I don't
>>> consider the dozen or two remaining symbols from templaint constraints
>>> and function arguments to provide much overhead.  Rather, I consider the
>>> weight of this additional syntax, ie the cognitive overhead from having
>>> to remember and parse more syntax in my head, to be worse than the
>>> remaining dependency reasoning problem you're trying to solve: the cost
>>> outweights the benefit.  Perhaps that's subjective and others may
>>> disagree.
>>>
>>
>> It is subjective and difficult to convert into action. Online review
>> among folks who know next to nothing about each other does have its
>> challenges. What happens here is I post a proposal for a problem that I
>> believe is important for large D projects. And I get back "eh, that's not
>> as important to me." At a traditional work place we'd know a lot about one
>> another's strengths, specialization areas, and design sensibilities. Here,
>> all I can do is look at your past PRs (that's why I emailed you asking for
>> your github handle; I figure it's @joakim-noah). This makes it difficult to
>> act on "I don't buy it" feedback.
>>
>> Now, there's also the question of purely technical benefits, like
>>> compilation speed or executable bloat.  I looked at the latter a little
>>> last summer, after Ilya had cleaned up a lot of the standard library:
>>>
>>> http://forum.dlang.org/thread/gmjqfjoemwtvgqrtdsdr@forum.dlang.org
>>>
>>> I found that commenting out a single scoped, selective import of
>>> "std.string: format" in std.utf led to a 5% decrease in executable size
>>> for "hello world."  This is a problem with how dmd compiles or appends
>>> these module dependencies and would presumably still be there after this
>>> DIP, as you would not remove the dependency.
>>>
>>
>> That might be a related but distinct issue. Can you reproduce that
>> experiment?
>>
>> I think scoped, selective imports have been great at hacking away at the
>>> module dependency graph, as you lay out.  It is not clear what technical
>>> costs you see from the remaining few dependencies and if this DIP is the
>>> best way to remove them.  I think you should explain why you want to
>>> untangle the remaining dependency graph, and consider if this DIP is
>>> really doing that much.
>>>
>>
>> I've made a few more passes through the DIP, but throughout I assume a
>> couple of things without stressing them too much - dependencies are
>> important, and associating dependencies with declarations makes the
>> dependency graph as fine and as precise it could get. I don't see a
>> reasonable way to make it better or clearer.
>>
>> Should I add an introductory section on why dependencies are important?
>>
>>
>> Andrei
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20161219/17c37ee8/attachment-0001.html>