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, Go and Rust have a clear roadmap how their future is
> supposed to look like, and drive just in that direction, with C++ taking
> all remaining good D ideas.
>
> This DIP discussion and the latest ones about splitting the runtime
> again, don't do anything to earn D any credibility it might still have
> left.

Thanks for taking the time to write this. All languages have an improvement process, which runs as a background task that is not always correlated with the current principal objectives of the language's leadership. We have recently improved our DIP process, but positive examples of compelling DIPs are missing. We were facing the problem that upcoming DIPs, if unguided, could create busywork for the leadership on trivial matters. Whether approved, rejected, or put on hold, DIP1005 will serve as a yardstick for future DIPs regarding the necessary work involved in defining the problem, investigating it as rigorously as possible, comparing with alternatives, and defining the feature.

Walter and I do agree that the DIP is ahead of its time because (a) there are more pressing and more important matters to keep me busy, and (b) encapsulation in D is a larger topic that we haven't yet put front and center because of (a).

For DIP1005 I invite interested collaborators to contact me about future iterations; it is important for the matter of encapsulation and also for the meta-challenge of setting an example for other DIPs to follow. Thanks.


Andrei

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 get convinced of anything, they won't be overwhelming so you may already write off DIP1005 as useless." -- Andrei

On Tuesday, 3 January 2017 at 09:28:06 UTC, Paulo Pinto wrote:
>
> Allow me just to share a worthless outsider opinion.
>
> I never contributed anything worthwhile and decided it was better to just focus on JVM, .NET languages., alongside C++, as those are the skills I get paid for, thus stop polluting D forums.
>
> 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.

Without listing what you think those real issues are, such a pronouncement is useless.

> Meanwhile Swift, Go and Rust have a clear roadmap how their future is supposed to look like, and drive just in that direction, with C++ taking all remaining good D ideas.

Heading in the wrong direction at full speed ahead is worse than meandering along in no discernible direction, because worst case, you will likely be closer to the right direction after simply meandering.  In any case, you clearly think D headed in some good directions, or C++ would have nothing to copy. ;)

As for the other roadmaps, I see it for Rust and Swift

https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-roadmap-2017.md
https://github.com/apple/swift-evolution

but nothing for Go.  Do you mean these milestone lists with hundreds of PRs attached?

https://github.com/golang/go/milestones

Or is it somewhere else that google can't easily find it?  You could read the changelog for the dmd/phobos master branches and get the same result as that Go list.

Those languages are all backed by large tech companies and are driven by their company agendas.  As I've pointed out in this forum before, with some quotes from Linus (http://forum.dlang.org/post/dluoruxmwxnfjtyvmgbh@forum.dlang.org), directed development is good for niches, which is where all those languages are now (iOS, network services, Servo), but only general-purpose tech lasts in the medium- to long-term.

D may never gain the resources it needs to make it that long, but a community employing D in _no one direction_, as Linus says happened with linux, is more likely to make it general-purpose enough to survive.

> This DIP discussion and the latest ones about splitting the runtime again, don't do anything to earn D any credibility it might still have left.

I kind of agree that both are not that worthwhile, but without stating your reasons for thinking the discussion _alone_ hurts D's credibility, which I mostly disagree with as such discussion is a core part of the distributed OSS process, that opinion is again useless.

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 importance; the first and foremost
>>> benefit of DIP1005 is it closes the gap on dependency encapsulation,
>>> which had been very successfully narrowed by local imports.
>> I love that idea. But I still can't see why this requires any new
>> syntax. Simply extending the scope of local inports to include the
>> function header is enough.
>
> I'll mention this possibility in the DIP.
Good.
>
>> Only for .di-generation it may be useful to move all local imports to
>> the declaration (maybe with this new syntax "with" before it) - but that
>> should be done with ALL local imports, because today the .di-files are
>> incomplete and will stay so if the new syntax is introduced but
>> "old-style" local imports still valid and not exported to the .di.
>> Or the old local imports become deprecated together with the
>> introduction of the new "with" syntax and vanish soon after that.
>
> Local imports don't pertain to the interface, they are an implementation detail. Why would those be made a part of the .di?
.di are needed to ship with a library. If a function locally imports some type, the library is dependant on that import, so if I want to use the library, I have to install all stuff it depends on too. And to find out, what exactly the library depends on the .di is the place I look, so there need to be mentioned each and every import - no matter how deeply local that may be. If that is not the case it renders .di-files completely useless to me (as they are at the moment), because I need to find out the dependencies somewhere else (e.g. in some documentation of the library).
While it is likely that the dependencies of a library may be documented somewhere, this is not guaranteed. But .di-files are guaranteed to ship with a lib because else it cannot link - at least if it contains any templates, which is about 100% sure for a language like D. So I would like to see local imports in the .di-file, even if they are not strictly needed to compile because the imported types are not exposed in the function signature.

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 against inline imports apply equally to nested imports. Come to think of it, lazy imports vs nested imports:
>
> * same improvement in compilation speed? check
> * no language changes? check
> * no nasty bugs in the aftermath (such as the infamous https://issues.dlang.org/show_bug.cgi?id=10378)? check
> * scalable builds? check
>
> Yet local imports are overwhelmingly superior to lazy imports because of one thing: they localize dependencies. They introduce modularity and its ancillary perks (fast and scalable builds, easier review and refactoring) not by engineering, but by organically placing dependencies spatially with their dependents. (The scope statement does the same thing with temporal dependencies.) That the DIP does not make it clear that it is a necessary and sufficient extension of local imports is a problem with it.
>

There is a major difference with this DIP.

Lazy import is not a language change, but a compiler implementation detail. As such, it doesn't require a DIP or anything specific.

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 maintaining the limitation rather than removing it.

This DIP is a language addition. Therefore, contrary to nested or lazy import, the burden of proof is on it. This DIP should be considered as follow: how much complexity does it add and how much benefit does it bring, compared to alternatives.

The obvious benefit is localizing dependencies. I think I'm not too far off track by considering most of the speedup and scalable build can be achieved with lazy import and, while I'm sure there are example where this is superior, we are talking marginal gains as lazy and nested imports squeezed most of the juice already.

The cost is the language addition. The first obvious improvement that can be made to this DIP to reduce its cost is to not introduce a new syntax. As such, the addition is limited to allowing the existing syntax in a new place rather than adding a whole new syntax for imports.

I like the extra expressivity. I'm not 100% convinced it is worth the extra cost, but the more the cost is reduced, the more rational it seems to me that this option should be pursued.

> I now am really glad we slipped local imports before the formalization of DIPs. The feature could have been easily demeaned out of existence.
>

Good you also notice how broken the DIP process is.

One suggestion: let's keep the DIP describing the change to be made. Some examples are fine to illustrate, but it is not the DIp's purpose to be easy to understand or expand too much in argumentation, or it'll be useless as a spec document, and trying to have the DIP be a spec, a tutorial, a essay on why the feature, and so on just lead to endless rewriting lead to perpetual motion but no progress.

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 maintaining the limitation
> rather than removing it.
> ...

I don't fully agree. Nested imports, the way they have been implemented, pose a new symbol hijacking hazard.

(A symbol hijacking anecdote (not directly related): https://github.com/tgehr/d-compiler/pull/1#discussion-diff-89697186L85 )

> This DIP is a language addition. Therefore, contrary to nested or lazy
> import, the burden of proof is on it. This DIP should be considered as
> follow: how much complexity does it add and how much benefit does it
> bring, compared to alternatives.

It adds basically no implementation complexity [1]. I consider the benefit real, but minor enough to oppose the DIP based on its wacky syntax.


[1] Both static if and static foreach (once it lands) need the same kind of scoping rules.

On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:

> [1] Both static if and static foreach (once it lands) need the same kind of scoping rules.

Please do contact me if you are working on static foreach, there are dmd and implementation specific issues to be taken into account.

On Wednesday, 4 January 2017 at 16:03:29 UTC, Stefan Koch wrote:
> On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:
>
>> [1] Both static if and static foreach (once it lands) need the same kind of scoping rules.
>
> Please do contact me if you are working on static foreach, there are dmd and implementation specific issues to be taken into account.

I think the best path forward is to define them properly.

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 adds basically no implementation complexity [1]. I consider the benefit real, but minor enough to oppose the DIP based on its wacky syntax.
>
> [1] Both static if and static foreach (once it lands) need the same kind of scoping rules.

I know about [1], this is why I did not mentioned it. I don't really mind about implementation complexity, I care about complexity of the definition. For the following reasons:
 - If the implementation may be complex, it can be isolated and/or abstracted away.
 - Interaction with other parts of the language are more predictable, including future parts that do not exists yet.
 - It obviate the explosion of trivia experienced devs needs to know to use the language.

On 04.01.2017 17:03, Stefan Koch wrote:
> On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:
>
>> [1] Both static if and static foreach (once it lands) need the same
>> kind of scoping rules.
>
> Please do contact me if you are working on static foreach,

Not currently. I might implement it in https://github.com/tgehr/d-compiler soon though. I'll let you know.

> there are dmd and implementation specific issues to be taken into account.

What kind of issues? The compiler implementation shouldn't matter for the definition of the static foreach behaviour.

Generation of the sequence of values assigned to the loop variables should be exactly like runtime foreach, scoping of the loop variables should be local. For scoping of the declarations within the static foreach body, there are multiple possibilities. (The most obvious thing is to just insert them into the outer scope, but then we need some other improvements in order to avoid having to string mixin each and every declaration in the body.)

There are some questions about which dependency structures should be allowed for the loop aggregate and the declarations in the loop body, but I think this is mostly orthogonal to static foreach itself.