2 ms·

You can absolutely work around that: - Require an explicit initial value to be provided. - Or require that a collection/iterator/generator of values be provid

You can absolutely work around that: - Require an explicit initial value to be provided. - Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough). - Or have a built-in ArrayBuilder<T> type that accumulates all the needed values before allowing you to retrieve the array. - Or make your language dependently typed, and change the signature of Array.get to take both an index and a proof that said index has been initialized.

SamReidHughes 11y ago
- Require an explicit initial value to be provided. Let's say you want an array of FileHandles. Under this proposal, you'd need to create an "empty" FileHandle value that you can use to fill arrays with and such. You'd have to create some "empty" state for every type. This is worse software engineering than having the possibility of a null pointer exception. (Also, you couldn't write generic code to implement an ArrayList<T> efficiently without some way to generically default-construct the T to fill most of the array entries, or the constructor would have to take a filler value.) - Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough). This is a needlessly complicated way to use an array, and it still has the same downsides. - Or have a built-in ArrayBuilder<T> type that accumulates all the needed values before allowing you to retrieve the array. And how do you implement your own ArrayBuilder? What if you need something with a slower growth rate, or some other data structure that you could build out of an array with uninitialized elements, such as a deque? - Or make your language dependently typed, and change the signature of Array.get to take both an index and a proof that said index has been initialized. A far worse alternative. Late edit: Generally speaking I think you're completely missing the problem of null pointers. The problem is not that a class of error exists. It's that people try to use null values in surprising ways in their APIs. If you make the null value impractical as a sentinel, you remove the mismatch between what programmers expect about whether a value can be null.

SamReidHughes 11y ago

- Require an explicit initial value to be provided. Let's say you want an array of FileHandles. Under this proposal, you'd need to create an "empty" FileHandle value that you can use to fill arrays with and such. You'd have to create some "empty" state for every type. This is worse software engineering than having the possibility of a null pointer exception. (Also, you couldn't write generic code to implement an ArrayList<T> efficiently without some way to generically default-construct the T to fill most of the array entries, or the constructor would have to take a filler value.) - Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough). This is a needlessly complicated way to use an array, and it still has the same downsides. - Or have a built-in ArrayBuilder<T> type that accumulates all the needed values before allowing you to retrieve the array. And how do you implement your own ArrayBuilder? What if you need something with a slower growth rate, or some other data structure that you could build out of an array with uninitialized elements, such as a deque? - Or make your language dependently typed, and change the signature of Array.get to take both an index and a proof that said index has been initialized. A far worse alternative. Late edit: Generally speaking I think you're completely missing the problem of null pointers. The problem is not that a class of error exists. It's that people try to use null values in surprising ways in their APIs. If you make the null value impractical as a sentinel, you remove the mismatch between what programmers expect about whether a value can be null.