On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote:
But the point is that so much time and effort is being spent on
discussing and designing a feature that you have admitted yourself to be
"rarely used". As a disinterested bystander I find it somewhat amusing
(and sad) to see so much over-engineering of an overly-complex system
involving a new basic type in the language, which in turn entails all
sorts of corner cases in how it will interact with existing types and
constructs, not to mention the implementation complexities that will be
involved to pull it off -- all for what? Just to be able to say
"function F doesn't return". Seems like disproportionate effort for
only marginal returns (har har).
The issue here (for me) is to have a type system that matches type systems used
in type theory. D already has strong abilities to do type calculus. Instead of
inventing our own whackadoodle scheme, one hack at a time, why not match
existing type calculus? Then, attempts to do type calculus in D will work as
worked out by type theory.
Or, we could go with the C++ approach which historically is to add an ad-hoc
solution for an existing problem, and then another ad-hoc solution for the
whacky effects that turned out to have, rinse, repeat. (Look at all the
different ways to do type deduction, a horrifying consequence. Or function
overloading, which started with complex special cases, then changed to partial
ordering for special cases.)
There is just something fundamentally wrong with:
@noreturn int foo();
returning a value yet not returning. It smacks of "the language designer(s) are
idiots." It winds up complicating things like:
auto x = a ? b : foo();
What is the type of x? @noreturn means a special case. A proper bottom type
means it is not a special case.
I recall that Rust initially did @noreturn as a special case, and later replaced
that with a bottom type and integrated it into the type system. I understand
that this had a positive ripple effect, such as reducing special cases in user
generic code.
Noreturn functions are just a happy fallout of doing this correctly in the first
place. The language semantics and compiler internals should be simpler and
cleaner by using accepted type theory.
