[killercup]

I especially like this approach:

> Often, the heart of the matter is the question of what to make implicit. In the rest of this post, I’ll present a basic framework for thinking about this question, and then apply that framework to three areas of Rust […]

What's proposed here is a universally good way to think about what to make implicit. The proposed changes to Rust are just some applications of this.

[zzzcpan]

"What's proposed here is a universally good way to think about what to make implicit."

I had a completely opposite reaction. It ignores all of the important things that make usability good and instead focuses on the approach that essentially promotes inconsistencies in design.

"The basic thesis of this post is that implicit features should balance these three dimensions. If a feature is large in one of the dimensions, it’s best to strongly limit it in the other two."

[kbenson]

Based on the actual examples, I'm not sure it promotes inconsistency in design, as long as it's not the sole deciding criteria. As a tool to do first pass exclusion of ideas I think it has a lot of promise.

The major problem I see is that it's fairly subjective at the moment in what you consider when thinking about those criteria. For example, in the section about eliminating the need for mod (which was admittedly presented as radical), the following was stated: You could instead imagine the filesystem hierarchy directly informing the module system hierarchy. The concerns about limited context and applicability work out pretty much the same way as with Cargo.toml, and the learnability and ergonomic gains are significant. I think this is a case where the learnability would suffer quite a bit. If I understand it correctly, this changes the filesystem from a unidirectional resource to a bidirectional one, where the presence of arbitrary files not specified (as opposed to a well understood singular file, such as Cargo.toml) might change how the code is interpreted.

[oconnor663]

I think the idea is that `foo::something()` without a module declaration either implies the existence of `foo.rs`, or fails to compile. I'd agree that it would be bad if creating `foo.rs` changed the behavior of code that was previously doing something else (other than breaking the build).

What would happen, I think, is that adding a `mod foo { ... }` definition would change the behavior of code that previously implicitly referenced a `foo.rs` file. But that seems less crazy to me, since you've got a change in one file affecting something else in that same file. Or it might make sense for that to be a "conflicting module definitions" error.

[killercup]

> It ignores all of the important things that make usability good

Can you give some examples?

To me the approach presented here is not just about coming up with an initial design (where I agree there are more aspects to be considered), but iterating on existing design aspects (in this case language syntax and semantics) to make them more useable. Seeing the first dimension the author mentions is 'Applicability' it seems they pay attention to consistency, but I can see it is not explicitly mentioned.

[zzzcpan]

Basics for good design is to satisfy all: simplicity, flexibility, consistency, universality, familiarity. So users won't have to neither learn a lot to do something simple nor learn a lot for a lot of different cases, but intuitively reuse what they already learnt across all similar cases.

So, what can be made implicit is irrelevant, the proper question would be what can be done to improve user experience. And it's a lot, but the design by committee kind of process is going to work against it.

[kzrdude]

> What's proposed here is a universally good way to think about what to make implicit.

You might want to vary your kool aid a bit!