--- Comment #15 from 2012-02-27 15:13:27 PST ---
(In reply to comment #14)
> There's also:
> arr = null;
> Would you have to change that to `arr = []` to fit the enhancement request?
> That would break so much code. 
> I see no benefit to banning the usage of null.

In well designed language it's good for different literals to represent
different things. Ideally a 1:1 relation. This avoids troubles, and makes code
reading and writing less bug prone and clear. In practice such 1:1 relation is
not always possible or desirable, but it's a line guide still.

In D there is already a literal that represents "empty array". Using two
different literals to represent the same thing is not so do. And especially so
if one of them looks much fitter to represent something else.

[] is a very good literal to represent an empty array (elsewhere I have
suggested to use [:] as literal to represent empty associative array, but this
is not present in D), it's clear and natural for this purpose.

In D "null" is a good literal to represent a pointer pointing to the default,
zero address, etc.

Since some time ago in D the concept of array was conflated with the concept of
pointer (well, fat pointer). Some of my bug reports on this have being accepted
and implemented, and lately arrays are behaving less and less as pointers.
Refusing "null" as literal for an empty array is another step in such good

In D there is some confusion between empty array and null array. It's a problem
that comes out all the time for D newbies, this is the last thread:

It's not just a problem for newbies, here there is a source of bugs for people
that know some more D too.

I am aware this is a small breaking change. And Walter and Andrei have the
right to close down this enhancement request if they want so. But there are
solid reasons behind this enhancement request.

> Next time you talk about clarity take a look at your own code first.

I don't write code like that in production code.

Code is written or copied for various levels of intended usage. There are
5-minutes snippets, code for quick benchmarks or tests to show to other people,
code written for online "code golf" contests, routines for small games written
in a weekend, code that must be used in critical situations, library code that
must be as much bug-free as possible, etc. They naturally have different level
of bug-count, clarity, compactness, documentation, amount of contracts and
preconditions and unit-tests, amount of brain work done on them, etc. It's
wrong to think all of them must have the same characteristics and qualities.

But the most important things you are missing are:
- This enhancement request is about _language design_.
- Bugzilla is not the place for discussions about persons.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to