On 07/12/2017 05:32 AM, Timon Gehr wrote:
On 09.07.2017 23:45, Meta wrote:
...
Another case that we should probably just statically disallow:
... > This obviously doesn't make any sense anyway
... > I don't see a reason for us to ever need to do that
Sorry, but this thinking has no place in type system design. This is
precisely how you create a convoluted nonsensical mess.
Timon, I think you're very well positioned to author a DIP on this.
Getting through acceptance on your static foreach DIP seems to not
require a lot of extra work.
Every type is peculiar. That's essentially the point of having
types. There is not really a reason to invent a peculiarity ordering
and then add additional special casing for types deemed more
peculiar. (I.e., creating different types of types based on an
informal judgment of peculiarity.)
I seem to recall Haskell calls those "kinds".
In D, subtyping is messy anyway, as you cannot have a subtyping
relationship between values with different memory layout. Hence in D,
Bottom would not actually be a subtype of all other types.
It's a point, and it would make the implementation easier, but it would
be a departure from theory. Also it makes user code a tad more awkward.
Consider:
typeof(assert(0)) abort(const(char)[] message);
...
int fun()
{
int x;
...
return x != 0 ? 1024 / x : abort("Error: calculation went awry.");
}
I guess such expressions can be rewritten into separate statements:
if (x != 0) return 1024 / x;
abort("Error: calculation went awry.");
and then the compiler figures there's no need for a return following the
call to abort.
Perhaps a solid plan is to start with a DIP that does not introduce
conversion and then experiment with the result for a while. What do you
think?
Andrei
