Hello Ary,
Don wrote:
BCS wrote:
Hello Ary,
Don wrote:
Phil Deets wrote:
On Mon, 28 Dec 2009 16:18:46 -0500, Simen kjaeraas
<[email protected]> wrote:
Apart from C legacy, is there a reason to assume anything we
don't
know what
is, is an int? Shouldn't the compiler instead say 'unknown type'
or
something
else that makes sense?
C++ abandoned default int. I think it would be best for D to do
the same.
D never had default int. When there's an error, the compiler just
has to choose *some* type, so that it doesn't crash <g>.
It could be an Error type (that's not an alias for int type) that
don't start to spit errors everywhere and instead just blocks all
further errors on that type.
that poses an interesting question: what "type" does this this give?
int i;
char[] s;
int foo(int);
char[] foo(int,char[]);
int[] foo(char[],int);
auto whatType = foo(i ~ s, s);
i~s gives the error type but DMD could tell that as long as the
other args are correct, the only foo that works returns a char[] so
does the variable get the error type or char[]?
Error.
Exactly! You would get an error saying "i ~ s" cannot happen, then it
resolves to the Error type. Now resolution of "foo" is not done (or
yes: it defaults to Error) because it has an argument of type Error
(one less error in the console is shown). Since foo is error, whatType
is Error. Then if whatType is used it won't trigger errors. Etc.
You would get a single error in the precise position you need to
correct it, instead of one error hidden with other many unrelated
errors.
IIRC, all of the above is planned and in the works.
The only point I was wondering about is should DMD attempt to resolve functions
where args are of error types? My thought is that in some cases it could
resolve it and detect real errors down the line. OTOH, the argument for this
(that blind propagation of Error can disable type checking on large swaths
of code, even across functions via template code and auto return) is also
an argument for why it could be a disaster if it makes the wrong guess.
