On Wednesday, 26 February 2020 at 15:41:48 UTC, Arine wrote:
Yah, what's unwanted about that?
To follow up on this, I expect a reply will be "the user ought to know how the feature works". This isn't a realistic expectation.
This is why I put in my little narrative in the new DIP, though it is deleted now since everyone else thought it was too anecdotal...
But as many of you know, I try to help D users pretty regularly, both existing D users with tricky questions and new D users who just aren't familiar with the language yet. I've answered about 1/5 of all stack overflow D questions myself, am often in the IRC channel to answer user questions, and read every post in the D.learn forum, again answering many myself.
So I see a lot of frequently asked questions and have developed a bit of a feel for where people common have trouble.
The #1 category of new or infrequent user difficulties is mismatched expectations coming from another language. A compile error is a chance to educate them as to D's difference, why it is that way, and how they can make it work for them. That's why I want a compile error on misuse. A type mismatch is the standard way we achieve this.
A quick run time error (e.g. null pointer segfault) results in users figuring it out on their own or asking us fairly quickly, but risks additional frustration since it is more delayed from the build.
But code that looks right to someone coming from another language yet silently doing weird stuff at runtime... I guarantee you would-be converts to D will find that really confusing and frustrating. Every single book or tutorial on D will have to call this out specifically. Every single usage example will have to point out the mismatched expectations.
Of course the spec will say it, but people often don't read the spec. (How many times have you seen people ask if D's `private` keyword is buggy?)
And a lot of new users will make the mistake anyway. We can prevent that with this simple, proven solution.
