Steven G. Johnson

@tknopp, I'm not saying you shouldn't use the constructor. I'm saying that _if_ a `calloc` version is fast enough then we need not provide a high-level uninitialized-array constructor (nor "a...

I made an experimental branch that uses `calloc` instead of `malloc`, and so far I haven't been able to detect any performance differences (all the differences are swamped by the...

@ScottPJones, for large arrays, I couldn't measure any performance penalty to `calloc` (any difference from `malloc` was in the noise). As I understand it, modern `calloc` implementations don't actually `memset`...

Maybe we could add a method `lu!(F::LU, A::AbstractMatrix)` that takes a pre-existing factorization object `F` and overwrites it with the factorization of `A` (a matrix of the same size). That...

I don't think it is feasible to change the behavior of `\` at this point. A more helpful error message is very possible, however. However, we might need to add...

Should we close as a duplicate of 28827?

It might be possible to provide this in a package (via macro syntax + overloaded `getproperty`). See e.g. [BitStructs.jl](https://github.com/rryi/BitStructs.jl) for one possible work in progress.

Yes, this certainly makes sense to me. We already have specialized methods for `partition(array, n)` that return views, so why not a specialized method for `partition(string, n)`?

Should just need something like: ```jl eltype(::Type{PartitionIterator{T}}) where {T collect(Iterators.partition("foobars", 2)) 4-element Vector{SubString{String}}: "fo" "ob" "ar" "s" ```

This is a user-visible change, but I don't think it would qualify as breaking since the only documented requirement of `partition` is that it returns iterable collections of elements, I...