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

On Tuesday, 3 January 2017 at 20:07:59 UTC, Andrei Alexandrescu wrote: Arguing that local imports have been successful so we should simply do more of it is not a good argument, as there comes a point of diminishing returns. You need to show that there are still worthile gains to be made from

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

On 05.01.2017 01:51, Andrei Alexandrescu wrote: On 12/31/16 9:43 AM, Timon Gehr wrote: On an unrelated note: I'm still not a fan of the with(import) syntax as it morally promotes a lack of turtles (even if not technically so). Could you please provide more detail? Thanks! -- Andrei The

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

On 12/31/16 9:43 AM, Timon Gehr wrote: On an unrelated note: I'm still not a fan of the with(import) syntax as it morally promotes a lack of turtles (even if not technically so). Could you please provide more detail? Thanks! -- Andrei

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

On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote: I don't fully agree. Nested imports, the way they have been implemented, pose a new symbol hijacking hazard. I'd argue this was an existing bug in import handling. This is why I like to have very orthogonal definitions. It

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

On 04.01.2017 16:00, deadalnix wrote: Nested import are a language simplification. Declaration can appear anywhere, import is a declaration, the fact that import couldn't appear anywhere was an arbitrary limitation, and removing it makes the language simpler. As such, the burden of proof is on

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

There are quite a few fallacies in there. On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: Regarding the ongoing doubts about the advantages of inline imports: they are first and foremost a completion of the nested import feature. As such, most, if not all, arguments

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

On Tuesday, 3 January 2017 at 12:57:22 UTC, Andrei Alexandrescu wrote: On 01/03/2017 02:19 AM, Dominikus Dittes Scherkl wrote: On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: DIP1005 gives consideration to the speed of compilation aspect in larger proportion than speed's

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

On 01/03/2017 03:07 PM, Andrei Alexandrescu wrote: If you're waiting for the numbers to get convinced of anything, you already consider DIP1005 useless. Eh, sorry, this came out wrong - as if I'm trying to put words in someone's mouth. I meant to say: "If you're waiting for the numbers to

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

On 01/03/2017 04:28 AM, Paulo Pinto wrote: Looking from the outside, and watching what was reached from 2016 roadmap, it is clear the DIPs evaluated thus dar aren't about fixing the library or runtime issues that prevent D's adoption at large as a systems programming language. Meanwhile Swift,

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

On 01/03/2017 03:10 AM, Joakim wrote: On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: Regarding the ongoing doubts about the advantages of inline imports: they are first and foremost a completion of the nested import feature. As such, most, if not all, arguments against

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

On Tue, 03 Jan 2017 08:10:04 +, Joakim wrote: > Except that almost nobody has argued against local imports. Rather, the > argument is that local imports mostly solved this problem, so why bother > adding new syntax for the dozen remaining symbols from 2-3 modules that > are commonly used in

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

On 01/03/2017 02:19 AM, Dominikus Dittes Scherkl wrote: On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: DIP1005 gives consideration to the speed of compilation aspect in larger proportion than speed's importance; the first and foremost benefit of DIP1005 is it closes the

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

On Tuesday, 3 January 2017 at 10:18:57 UTC, Daniel N wrote: static if(is(isArray(...))) { import std.range : join; join(...); } PS Actually double {} is needed for the 'alternate' style to be meaningful, preventing the import from bleeding into the outer scope. static if(isArray(...))

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

On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: No worries, I'll make a pass (a rewrite, really) taking all feedback into account. Are all the proposals mutually exclusive? When it comes to declarations, the DIP actually won me over! However I was hoping for it to

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

On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: On 12/31/2016 12:20 PM, Martin Nowak wrote: On Saturday, 24 December 2016 at 10:54:08 UTC, Stefan Koch wrote: If that were made more lazy, we could import half of the world with noticing impact. (Which espcially in

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

On Tue, 03 Jan 2017 07:19:41 +, Dominikus Dittes Scherkl wrote: > On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: >> DIP1005 gives consideration to the speed of compilation aspect in >> larger proportion than speed's importance; the first and foremost >> benefit of

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

On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: Regarding the ongoing doubts about the advantages of inline imports: they are first and foremost a completion of the nested import feature. As such, most, if not all, arguments against inline imports apply equally to nested

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

On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: DIP1005 gives consideration to the speed of compilation aspect in larger proportion than speed's importance; the first and foremost benefit of DIP1005 is it closes the gap on dependency encapsulation, which had been very

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

On 12/31/2016 12:20 PM, Martin Nowak wrote: On Saturday, 24 December 2016 at 10:54:08 UTC, Stefan Koch wrote: If that were made more lazy, we could import half of the world with noticing impact. (Which espcially in std.traits, would not make that much of a difference since every template in

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

On Mon, 02 Jan 2017 00:47:41 +, pineapple wrote: > On Saturday, 31 December 2016 at 17:02:55 UTC, Chris Wright wrote: >>> This extension removes an unforced limitation of the current with >>> syntax (allows it to occur at top level) >> >> In other words, another aspect of this DIP is that I

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

On 02.01.2017 01:47, pineapple wrote: On Saturday, 31 December 2016 at 17:02:55 UTC, Chris Wright wrote: This extension removes an unforced limitation of the current with syntax (allows it to occur at top level) In other words, another aspect of this DIP is that I can write: module foo;

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

On Saturday, 31 December 2016 at 17:02:55 UTC, Chris Wright wrote: This extension removes an unforced limitation of the current with syntax (allows it to occur at top level) In other words, another aspect of this DIP is that I can write: module foo; static import std.traits; static

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

On Saturday, 24 December 2016 at 10:54:08 UTC, Stefan Koch wrote: If that were made more lazy, we could import half of the world with noticing impact. (Which espcially in std.traits, would not make that much of a difference since every template in there depends on nearly every other template

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

On Tue, 13 Dec 2016 17:33:24 -0500, Andrei Alexandrescu wrote: > Destroy. > > https://github.com/dlang/DIPs/pull/51/files > > > Andrei > Inside any function, with (Import ImportList) is a statement that > introduces a scope. So I can't write: with (import std.stdio, std.conv) int count

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

On Sat, 31 Dec 2016 16:41:16 +, Chris Wright wrote: > Far less ambiguous, but your examples all have unmodified with-imports, > and you seem less than keen about selective imports. Correction: *tend to* have unmodified with-imports.

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

On Fri, 30 Dec 2016 20:56:54 -0500, Andrei Alexandrescu wrote: > On 12/30/16 7:32 PM, Chris Wright wrote: >> On Fri, 30 Dec 2016 22:42:39 +, Stefan Koch wrote: >> >>> On Friday, 30 December 2016 at 22:29:18 UTC, Chris Wright wrote: * Performance improvements, primarily when a module

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

On Saturday, 31 December 2016 at 15:05:00 UTC, Adam D. Ruppe wrote: Consider the following: with (import std.stdio) void process(File input) ; Let's rewrite that to be: template process() { import std.stdio; void process(File input) { } } I absolutely hate making functions

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

On Sat, 31 Dec 2016 15:05:00 +, Adam D. Ruppe wrote: > static import r = std.range.primitives; For that to pass code review, you'd need a readable name -- perhaps 'ranges' instead of 'r' -- which makes it more obvious, more searchable, and more typing. > with (import std.stdio) void

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

On Sat, 31 Dec 2016 07:23:14 -0500, Andrei Alexandrescu wrote: > On 12/30/16 11:10 PM, Chris Wright wrote: >> On Fri, 30 Dec 2016 21:13:19 -0500, Andrei Alexandrescu wrote: >>> DIP1005 can't be in the business of arguing that encapsulation is good >>> by means of examples. >> >> Right. I said we

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

On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files FYI, from the DIP, this is false: "The static import setup does not share the issue above, at the cost of being cumbersome to use---all imported symbols must use

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

On 31.12.2016 13:23, Andrei Alexandrescu wrote: On 12/30/16 11:10 PM, Chris Wright wrote: On Fri, 30 Dec 2016 21:13:19 -0500, Andrei Alexandrescu wrote: DIP1005 can't be in the business of arguing that encapsulation is good by means of examples. Right. I said we should talk about the

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

On 12/30/16 11:10 PM, Chris Wright wrote: On Fri, 30 Dec 2016 21:13:19 -0500, Andrei Alexandrescu wrote: DIP1005 can't be in the business of arguing that encapsulation is good by means of examples. Right. I said we should talk about the concrete benefits of the proposal instead of talking

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

On Fri, 30 Dec 2016 21:13:19 -0500, Andrei Alexandrescu wrote: > DIP1005 can't be in > the business of arguing that encapsulation is good by means of examples. Right. I said we should talk about the concrete benefits of the proposal instead of talking about encapsulation.

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

On 12/30/16 7:34 PM, Chris Wright wrote: On Fri, 30 Dec 2016 23:49:23 +, Andrei Alexandrescu wrote: The main win, which indeed is not emphasized enough, is better encapsulation. Walter pointed that out, and I will redo the DIP to put that front and center. Encapsulation is an abstraction

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

On 12/30/16 7:32 PM, Chris Wright wrote: On Fri, 30 Dec 2016 22:42:39 +, Stefan Koch wrote: 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

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

On Fri, 30 Dec 2016 23:49:23 +, Andrei Alexandrescu wrote: > The main win, which indeed is not emphasized enough, is better > encapsulation. Walter pointed that out, and I will redo the DIP to put > that front and center. Encapsulation is an abstraction over several concrete benefits. We're

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

On Fri, 30 Dec 2016 22:42:39 +, Stefan Koch wrote: > 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. Well, not today,

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

On Friday, 30 December 2016 at 23:49:23 UTC, Andrei Alexandrescu wrote: The main win, which indeed is not emphasized enough, is better encapsulation. Walter pointed that out, and I will redo the DIP to put that front and center. Maybe i can provide an example where i think DCD's would be

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

Stefan Koch wrote: > 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

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

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

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

On Fri, 30 Dec 2016 18:18:12 +, 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

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

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

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

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

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

On 12/28/16 9:47 PM, Chris Wright wrote: On Wed, 28 Dec 2016 15:48:46 +, 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

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

On Wed, 28 Dec 2016 15:48:46 +, 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 > >

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

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

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

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

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

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

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

On Sat, 24 Dec 2016 17:45:35 +, 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)

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

On Sat, 24 Dec 2016 14:10:30 -0500, Andrei Alexandrescu wrote: > On 12/24/2016 12:45 PM, 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. > > When it was shorter, people complained it had too little information. It's

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

On Sat, 24 Dec 2016 14:03:26 -0500, Andrei Alexandrescu wrote: > * Your post provided no description of the methodology used beyond > "relatively simple regex" to come up with the magic number 26, so I > tried to use interpretation. > > * There is no answer to "where is cmp on that list for

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

On Fri, 23 Dec 2016 23:41:46 -0500, Andrei Alexandrescu wrote: > On 12/23/16 9:23 PM, Chris Wright wrote: >> The comparison to mach.d is a strawman. > > The mach.d is given as an example of the approach of breaking code into > fine-grained module. No comparison is made or implied. "Assuming

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

On 12/24/2016 02:16 PM, Joakim wrote: On Saturday, 24 December 2016 at 17:53:04 UTC, Chris Wright wrote: On Sat, 24 Dec 2016 09:20:19 +, John Colvin wrote: There are a lot of templates in Phobos that never use the template keyword. The proposal doesn't only apply to constraints, it applies

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

On 12/24/2016 02:03 PM, Andrei Alexandrescu wrote: With no top-level imports and all imports hoisted into inline imports, the fixed cost of importing one module will be that module alone. I'd really like to clarify this because that's where scalability comes from. The moment you need to open

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

On Saturday, 24 December 2016 at 17:53:04 UTC, Chris Wright wrote: On Sat, 24 Dec 2016 09:20:19 +, John Colvin wrote: There are a lot of templates in Phobos that never use the template keyword. The proposal doesn't only apply to constraints, it applies to the whole declaration. If you

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

On 12/24/2016 12:45 PM, 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. When it was shorter, people complained it had too little information. If you're using the text form, the nicey formatted version may be helpful:

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

On 12/24/2016 12:52 PM, Chris Wright wrote: On Sat, 24 Dec 2016 04:34:03 -0500, Andrei Alexandrescu wrote: Upon more investigation, I see a large discrepancy between the findings of DIP1005 and yours. There's no discrepancy. In part, you are misinterpreting most of what I said. Yah, I

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

On Saturday, 24 December 2016 at 17:52:04 UTC, Chris Wright wrote: The minimum isn't terribly useful because it gets to the point of testing the process scheduler and IO more than the compiler. If we want numbers that we can trust on the low end, we'll need to put timing information into the

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

On Sat, 24 Dec 2016 04:34:03 -0500, Andrei Alexandrescu wrote: > Upon more investigation, I see a large discrepancy between the findings > of DIP1005 and yours. There's no discrepancy. In part, you are misinterpreting most of what I said. In part, you are assuming that imports on non-template

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

On Sat, 24 Dec 2016 09:20:19 +, John Colvin wrote: > There are a lot of templates in Phobos that never use the template > keyword. The proposal doesn't only apply to constraints, it applies to > the whole declaration. If you have a better way of estimating the impact, I'd love to see it.

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

On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu wrote: On 12/24/16 9:20 AM, Stefan Koch wrote: On Saturday, 24 December 2016 at 14:08:48 UTC, Andrei Alexandrescu wrote: On 12/24/2016 05:54 AM, Stefan Koch wrote: If that were made more lazy, we could import half of the world

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

On 12/24/16 9:20 AM, Stefan Koch wrote: On Saturday, 24 December 2016 at 14:08:48 UTC, Andrei Alexandrescu wrote: On 12/24/2016 05:54 AM, Stefan Koch wrote: If that were made more lazy, we could import half of the world with noticing impact. That is what 1005 will bring. -- Andrei A

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

On Saturday, 24 December 2016 at 14:08:48 UTC, Andrei Alexandrescu wrote: On 12/24/2016 05:54 AM, Stefan Koch wrote: If that were made more lazy, we could import half of the world with noticing impact. That is what 1005 will bring. -- Andrei A compiler enhancement can do this _without_ a

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

On 12/24/2016 05:54 AM, Stefan Koch wrote: If that were made more lazy, we could import half of the world with noticing impact. That is what 1005 will bring. -- Andrei

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

On Saturday, 24 December 2016 at 10:54:08 UTC, Stefan Koch wrote: 300 microseconds, which is not even 0.3% of the time spent. Lexing them requires additionally also about 300 microseconds. So Together that makes up 0.6% of the time spent. Of course in the above 3% and 6% are the right numbers.

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

On Saturday, 24 December 2016 at 09:34:03 UTC, Andrei Alexandrescu wrote: (I confirm that importing std.traits, std.meta, and std.range.primitives together takes 10ms.) while compiling std.traits 6 files are opened and read into memory, taking roughly 300 microseconds, which is not even 0.3%

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

On 12/23/2016 09:23 PM, Chris Wright wrote: [abbreviated below] Upon more investigation, I see a large discrepancy between the findings of DIP1005 and yours. So there are a number of claims here, which I'll summarize: tldr: the performance impact of this DIP would be too small to easily

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

On Saturday, 24 December 2016 at 02:23:53 UTC, Chris Wright wrote: Appendix A: templates that would receive 'with(import foo)' in Phobos. I used a relatively simple regex to look for this. If someone put more than one line between a template and its constraints, or comments with certain

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

On 12/23/16 9:23 PM, Chris Wright wrote: The comparison to mach.d is a strawman. The mach.d is given as an example of the approach of breaking code into fine-grained module. No comparison is made or implied. Then I looked at the code. Phobos has 26 templates that would use this special

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

tldr: the performance impact of this DIP would be too small to easily measure and only impacts 26 declarations referencing 14 templates in the standard library anyway. On Fri, 23 Dec 2016 18:55:25 -0500, Andrei Alexandrescu wrote: >> I grant that everyone uses phobos, and phobos uses template

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

On 12/23/2016 05:33 PM, Chris Wright wrote: On Fri, 23 Dec 2016 11:25:41 -0500, Andrei Alexandrescu wrote: Dependency-Carrying Declarations allow scalable template libraries. template libraries *This* is the part I hadn't noticed before, and it explains the confusion I had. If you *only*

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

On Fri, 23 Dec 2016 11:25:41 -0500, Andrei Alexandrescu wrote: > Dependency-Carrying Declarations allow scalable template libraries. > template libraries *This* is the part I hadn't noticed before, and it explains the confusion I had. If you *only* apply this to templates, it works. The

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

Major update adding an experiment that shows the cost of top-level imports. https://github.com/dlang/DIPs/pull/51 https://github.com/dlang/DIPs/blob/a3ef4e25cfb9f884fee29edb5553a3a2b840f679/DIPs/DIP1005.md Relevant added text: Another matter we investigated is how reducing top-level imports

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

On Fri, 23 Dec 2016 07:48:55 -0500, Andrei Alexandrescu wrote: > On 12/22/16 10:31 PM, Chris Wright wrote: >> It's two benefits for one disadvantage. > > One won't make decisions by taking the difference of pros and cons, > right? -- Andrei You'd use the weighted difference, naturally.

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

On 12/22/16 9:53 PM, Chris Wright wrote: In point of fact, selective and static imports should be *faster* than Andrei's way. Consider: static import myapp.users, std.socket; bool isUserOnline(myapp.users.User user, std.socket.Socket socket); This has to locate a declaration named `User`

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

On 12/22/16 9:53 PM, Chris Wright wrote: bool isUserOnline(User user, Socket userSocket) import myapp.users, std.socket; Has changed to with (import myapp.users, std.socket) bool isUserOnline(User user, Socket userSocket); Andrei

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

On 12/22/16 10:31 PM, Chris Wright wrote: It's two benefits for one disadvantage. One won't make decisions by taking the difference of pros and cons, right? -- Andrei

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

I'm looking at this part: > The manual conversion of std.array to the "static import" form is shown > here. It leads to the expected lengthening of the symbols used in > declarations, which appears to eliminate one disadvantage by > introducing another. You get longer declarations when you're

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

On Thu, 22 Dec 2016 10:17:33 +, Joakim wrote: > Opening a file or 10 is extremely cheap compared to all the other costs > of the compiler. Purely from a technical cost perspective, > I'm not sure even scoped imports were worth it, as my simple > investigation below suggests. The compiler

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

On 12/22/2016 05:17 AM, Joakim wrote: On Wednesday, 21 December 2016 at 15:16:34 UTC, Andrei Alexandrescu wrote: In first approximation, whether a file gets opened or not makes a difference (filesystem operations (possibly including networking), necessity to rebuild if dependent code is

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

On Wednesday, 21 December 2016 at 15:16:34 UTC, Andrei Alexandrescu wrote: On 12/20/2016 11:32 PM, Joakim wrote: (...) I don't know how to make matters much clearer than the current document. Any suggestions are welcome. The section "Workaround: Are Local Imports Good Enough?" discusses the

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

> I just tried compiling phobos and its unittests for dmd 2.066.1 and 2.067.1 I think it's worth considering compile time for partial recompilation as opposed to full compilation. The benifit of this DIP should be more pronounced there since there'll be more opportunities to skip parsing modules

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

On Wednesday, 21 December 2016 at 15:16:34 UTC, Andrei Alexandrescu wrote: On 12/20/2016 11:32 PM, Joakim wrote: Second, as I noted above, most top-level imports have not been made selective yet, because of the symbol leak bug that was recently fixed by Martin. You will see in my PRs that I

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

On 12/21/16 6:40 PM, Timothee Cour via Digitalmars-d wrote: Andrei: ping on this? (especially regarding allowing `:`) I think "lazy" is a bit too cute. "with" is so close to what's actually needed, it would be a waste to not use it. Generally I'm weary of the use of ":" (never liked it - it

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

On Mon, Dec 19, 2016 at 9:33 PM, Timothee Cour wrote: > 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

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

On 12/20/2016 09:31 AM, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades

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

On 12/20/2016 11:32 PM, Joakim wrote: On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote: Thanks for this analysis of the remaining dependency graph, it is worth looking at. Allow me to poke some holes in it. To begin with, the amount of scoping that has been done is

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

On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote: I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365

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

On 12/20/2016 05:08 PM, Andrei Alexandrescu wrote: On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a

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

On 12/20/2016 05:08 PM, Andrei Alexandrescu wrote: On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a

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

On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a smoking gun, and one has been found. I have just

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

On 19.12.2016 06:31, deadalnix wrote: On Sunday, 18 December 2016 at 23:18:27 UTC, Andrei Alexandrescu wrote: Great, thanks. Please take a look at the accuracy of the discussion. I expanded the "Workaround" section and moved it near the top. https://github.com/dlang/DIPs/pull/51

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

On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote: I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365

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

I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365 https://github.com/dlang/phobos/pull/4370

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

On 12/20/2016 09:31 AM, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades

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

On Tuesday, 20 December 2016 at 01:06:01 UTC, Andrei Alexandrescu wrote: Pushed again, now with the syntax using "with" proposed by Hatem Oraby and others. https://github.com/dlang/DIPs/pull/51 https://github.com/dlang/DIPs/blob/71bde077488b566fba7603de6095b45984d9294a/DIPs/DIP1005.md

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

On Tuesday, 20 December 2016 at 14:31:38 UTC, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g.

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

On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades to countless instances of import statements.

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

On Tuesday, 20 December 2016 at 04:04:14 UTC, Andrei Alexandrescu 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

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

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

  1   2   3   >