Downsides to depending `mutable` field on `DataType`?

General Usage
1

I need to check if a user defined type passed as an argument to a generated function is mutable or immutable (I’m doing a recursive vector of structs → struct of vectors transform, and I only want to split fields that are mutable all the way from the root type).

I’m aware DataTypes have a mutable field, and I suspect that’s not going anywhere. However this feels sort of brittle to me, and I wanted to check that I’d not be committing some huge wtf by defining:

abstract type Mutability end
struct Mutable <: Mutability end
struct Immutable <: Mutability end

Mutability(::Type{T}) where {T} = T.mutable ? Mutable() : Immutable()
2

I am not sure I understand what you are trying to do, but there is isimmutable in Base, so you may not need traits.

3

isimmutable takes a value, and I need to generate a type based on the mutability of another type. Is there a way to get isimmutable working with a type?

4

If you have to operate on types, then accessing T.mutable is probably your best option.

But is hard to say more without context, can you make an MWE?

5

I don’t see any immediate reason to change this, but internal fields do move around sometimes. I’d take a PR to add an isimmutabletype(T::DataType) generic function that just returns that field. That’ll be easier to keep working than the raw field access.

3 Likes