On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote:
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.)
[...]
Agreed. Discovered vs invented as Philip Wadler classifies the
two approaches in his talk:
https://www.youtube.com/watch?v=IOiZatlZtGU, which I highly
recommend watching.
