Fix Issue 24215 - isBasicType!Enum should be false

[pbackus]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @pbackus! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	24215	normal	std.traits.isBasicType!Enum should be false

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#8838"

[pbackus]

Dub build failure is caused by this change somehow; time to investigate...

[thewilsonator]

Dependant PR merged.

[dkorpel]

Considering it broke a project on buildkite, it probably warrants a change log entry

[n8sh]

Hang on a minute! The way std.traits classifies types doesn't always line up with the language specification and nothing says it has to. For example as far as the D language is concerned char and bool are unsigned integer types but std.traits.isUnsigned and std.traits.isIntegral present a view of the world that draws a distinction between characters, boolean values, and numbers. Breaking changes to std.traits are particularly bad given how foundational it is. Even D programmers who use little else of Phobos rely on it.

Is there some common coding pattern using isBasicType that runs into problems if the programmer doesn't explicitly consider enums and exclude them? That would be a decent reason to consider changing it.

[pbackus]

I wanted this version of isBasicType for my safe allocators project, but I ended up finding a different solution to the same problem. So at this point it's just a UX issue.

If consensus is that this is too risky, I'm fine with reverting it. We can revisit for Phobos v2, if and when that ever happens.

@atilaneves, thoughts?

[atilaneves]

If there are issues and you have a workaround, I say it's better/easier to revert.