On Friday, 19 August 2016 at 21:51:38 UTC, Engine Machine wrote:
On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta
wrote:
1) `null` has a very precise meaning: it is the only valid
value of an unnamed type only known as `typeof(null)`, which
implicitly converts to any class/pointer/dynamic
array/associative array type. Thus this thing should have a
different name.
null as many interpretations. It is ok to expand the meaning.
It is done all the time. If it confuses you are creates a
semantic difficulty, I don't mind what it is called. It could
be called Boomfurkasufasdf.
In this case, defining it to be null fits in semantically
though. If it creates some compiler issue then, again, anything
else could be used. I'd prefer Null or NULL or Aleph or
something short and meaningless.
The problem is that null is a valid value to instantiate an alias
template parameter with. So using it to do something completely
different may create ambiguity (does that null means "parent
template" or is it a valid instantiation? Who knows). But as you
said, this is just a matter of finding a name.
2) What about this case:
```
class Type(T): Type
{
static if (T is Dog)
int y;
else
float z;
}
```
What should be inside the base?
z.
This is wrong. If Type has to be the base class of every Type!T,
then it cannot contain z, as there is one Type!T (namely
Type!Dog) which does not contain z. So in this case the base
class Type should be empty. As you see it is not that simple.
I am after simplifying class design.
Fair enough. Though I'm not sure this is the right way to go.
4) I think that the value of this addition is little wrt. the
amount of work the compiler should do to implement it (which
at first sight would be a lot). But this is of course just my
opinion.
It is just syntactic sugar and requires no complex compiler
modifications. The benefit is reduced visual complexity and
that is always a bonus. That is the point we don't write in 0's
and 1's... everything else is just syntactic sugar. In this
case, it is a very simple rewrite rule. A few lines of code
would be all that is required.
I'm not an expert, but I think this requires *a lot* of compiler
work: it has to analyze every symbol in the class to find out
whether it must be part of the "uninstantiated" base or not. And
this kind of analysis may not be easy (it may be masked by the
use of traits, template mixins, string mixins and so on). Even
humans can easily get it wrong (see my previous example).
Also, I thought of other problems:
- Interaction with non-class templates: how should they behave?
Or are we just introducing a special case for class templates?
(Special cases are very bad, we should limit them).
- Interaction with base classes and interfaces: how is this
"uninstantiated base class" inserted into the graph of classes
and interfaces? Are interfaces considered implemented by this
base class? Is this base class inserted between the templated
class and the "original" base class?
