Takafumi Arakaki

Hi, I'm proposing a new AbstractSparseMatrixCSC interface in PR JuliaLang/julia#33054. We need to document the accessor functions so people here may be interested in the discussion there.

Let me summarize the recent changes I made related to this issue: In JuliaLang/julia#30173, @ViralBShah and I were discussing the way to expose SparseMatrixCSC functionality in such a way that...

Questions I'd like to ask here are: 1. What accessor function should we use for `colptr`? Should it be `coloffsets`? Should we just document and export `getcolptr`? 2. Should we...

Thanks. So @Sacha0, @ViralBShah, and I all seem to think that it makes sense to use `storedindices` or `storeinds` for `SparseVector` if `nonzeros` is renamed to `storedvals`. @Sacha0's comment also...

The only absolute blocker for `AbstractSparseMatrixCSC` JuliaLang/julia#33054 is the name of accessor function for field `.colptr`. Other accessor functions already exist as public API so we have to keep (at...

@mauro3 Actually, I was wrong to present it like `__fieldnames__` was the only solution. If you were going to overload `__fieldnames__` (and `constructorof`) via `struct`-generating macro anyway, it would be...

@rafaqz Are you talking about the restriction that the generator body has to be pure? But I guess it is not an issue here since we don't call API functions...

FYI some discussion of `if @generated` started in https://stackoverflow.com/questions/59601652/when-should-i-use-optionally-generated-functions

Maybe we can release 1.0 sometime soon? Maybe after bringing this up in discourse so that we can get some more feedbacks? I think `setproperties` and `constructorof` are pretty solid...

Yeah, the current implementation is rather sloppy. I guess probably the best strategy is to create a temporary file and log UUIDs in it.