If you could make any changes to D, what would they look like?

[H. S. Teoh]

On Mon, Oct 25, 2021 at 05:23:01PM +0000, Dennis via Digitalmars-d wrote:
[...]
> - Module constructors make it hard to see what's happening when the
>   program starts. I once submitted a D program for an assignment and
>   it failed because it loaded local files for unittests in a module
>   constructor, which I forgot to remove because I only looked at main.

But that's hardly the fault of module ctors. You're not supposed to do
unittest-related stuff outside of unittest blocks and stuff versioned by
`version(unittest)`.  What you *should* have done is:

	version(unittest) static this() {
		// load stuff you need for unittests here
	}

	// regular module ctor (yes you can have multiple static ctors,
	// they just get concatenated together -- this is actually a
	// feature).
	static this() {
		// DON'T do stuff here that's unittest-related!
	}


> - opDispatch: suddenly member introspection (`__traits(hasMember)`)
> succeeds when you don't expect it, so now it's accepted as a broken
> InputRange/OutputRange/whatever in generic functions.

I suspect part of this problem is caused by the lame specialcased
behaviour of template instantiation errors being ignored when it's
opDispatch.  It's D's version of C++'s SFINAE, which leads to all sorts
of stupidity like a typo inside opDispatch suddenly causing a dispatched
member to disappear from existence 'cos the compiler swallows the error
and pretends the member simply doesn't exist.  So if you're
introspecting the member, the introspection code doesn't even see it.
Which leads to hours of head-scratching over "I obviously declared the
darned member, why does the code NOT see it?!?!".

Errors in opDispatch seriously ought to be treated as errors. If some
member isn't supposed to be part of the dispatch, it should be checked
for in the sig constraint or something like that, instead of the
compiler silently swallowing the error.


> - alias this: I use it, I encounter
> [bugs](https://issues.dlang.org/show_bug.cgi?id=19477) and weird
> consequences like unexpected endless recursion, I remove it.

Yeah `alias this` beyond the most trivial of usecases leads to nothing
but pain.


> It's kind of like your quote from Discord:
> 
> > so many times a questions comes up in learn like "how would i do
> > this with metaprogramming" and im like "bro just use a standard
> > function like you would in javascript"
> 
> Nowadays whenever I can express something with plain old
> structs/functions/arrays/enums, I do that instead of anything fancy,
> and I'm liking the result.

Isn't this what we're supposed to be doing anyway?  I mean, you can do
*anything* with mixin(), but most of the time you shouldn't because
there are much more readable and maintainable ways to accomplish the
same thing. :-D


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler