std.data.json formal review

[Brad Anderson via Digitalmars-d]

On Thursday, 30 July 2015 at 04:41:51 UTC, Walter Bright wrote:
> I agree with your goal of readability. And if someone wants to 
> write code that emphasizes it's JSON, they can write it as 
> std.data.json.parseStream. (It's not about saving typing, it's 
> about avoiding extra redundant redundancy, I'm a big fan of 
> Strunk & White :-) ) This is not a huge deal for me, but I'm 
> not in favor of establishing a new convention that repeats the 
> module name. It eschews one of the advantages of having module 
> name spaces in the first place, and evokes the old C style 
> naming conventions.

Is there any reason why D doesn't allow json.parseStream() in 
this case? I remember the requirement of having the full module 
path being my first head scratcher while learning D. The first 
example in TDPL had some source code that called split() (if 
memory serves) and phobos had changed since the book was written 
and you needed to disambiguate. I found it very odd that you have 
type the whole thing when just the next level up would suffice to 
disambiguate it.

The trend seems to be toward more deeply nested modules in Phobos 
so having to type the full path will increasingly be a wart of 
D's.

If we can't have the minimal necessary module paths then I'm 
completely in favor of parseJSONStream over the more general 
parseStream. I want that "json" in there one way or another 
(preferably by the method which makes it optional while 
maintaining brevity).