Erik Schnetter

Found it... Was my mistake after all. The code below reproduces the problem: ```Julia using ComputedFieldTypes using StaticArrays using Grassmann # @basis 1 V = v1 Vec(X) = Chain{V,1,X} Mat(X)...

No, I don't need this at the moment.

I thought `map` performed a run-time check on the return value for a zero input to the mapped function. See e.g. https://github.com/JuliaSparse/SparseArrays.jl/blob/090474bec9de69d2573e816a6187568822f1d85a/src/higherorderfns.jl#L160 for sparse arrays: ```Julia function _noshapecheck_map!(f::Tf, C::SparseVecOrMat, A::SparseVecOrMat,...

Calling `iszero` on the result of `f` is more efficient that comparing to zero.

This problem isn't specific to `map`. One can define types where the result of `sin(zero(T))` has the same problem: ```Julia struct IntFillMatrix val::Int end ``` and its values are equivalent...

Also, the code e.g. for `inv` or `pinv` for diagonal matrices calls `zero(T)` on many occasions. I think we can deduce that `T = Matrix` isn't currently handled well.

Instead of initializing them to zero, we could initialize them to a large, nonsensical value to help catch access of uninitialized fields.

I'd be in favour of initializing everything. If this turns out to be a bottleneck, as measured in a validated benchmark, then we can see whether introducing `ccall(:jl_allocate_uninitialized_array)` for a...

The consensus that seems to form is that initializing newly allocated memory should be the default, for security reasons. (There should also be a sufficiently-obscure escape hatch for well-tested low-level...

@andreasnoack I agree.