Feature Request: Type Constraints

[willtebbutt]

Firstly, thank you for writing this package -- I wish someone had written this years ago haha.

One extra feature that would be cool to have would be type constraints on the concrete types. I'm imagining something like

@concrete struct Foo{T<:Real}
    x::T
    y<:Real
    z<:AbstractMatrix{T}
end

would be equivalent to

struct Foo{T<:Real, Ty<:Real, Tz<:AbstractMatrix{T}}
    x::T
    y::Ty
    z::Tz
end

[jonniedie]

Thanks!

That would be pretty nice to have. I'll lay out a few of my initial objections. None of them are really dealbreakers.

1. I think field_name<:TypeName kinda muddies the meaning of the <: operator. I personally tend to conflate <: with isa pretty often in normal code where I wonder why (3, 0) <: Tuple{Int, Int} returns false, especially when pulling out value-as-type parameterizations.

2. I'd like to keep the syntax standard enough that you can always remove the @concrete macro and still have a valid--albeit not concretely parameterized--struct definition. Admittedly, I don't have a good reason for this other than personal preference and I realize I'll probably have to be flexible on this one at some point. I already sorta broke this by introducing the terse keyword, but I consider that more as part of the @concrete macro as it's not in the body of the struct definition.

To work around objection 1, there could be the slightly uglier syntax of

@concrete struct SomeType{T}
    a::<:AbstractArray{T}
    b::T
    c
end

or maybe

@concrete struct SomeType{T}
    a isa AbstractArray{T}
    b::T
    c
end

Those still leave objection 2, but like I said, I'm not super firm on that one.

[willtebbutt]

Interesting.

An argument against point 2 would be that if one meant to create a concretely-typed struct but forgot the macro, having syntax that breaks your code might actually be a good thing in the sense that you wouldn't accidentally run the code and have to hunt down performance bugs 🤷

[jonniedie]

I decided to just go for it. I'm not going to document the feature just yet, because I'm still not 100% on the syntax.

[jonniedie]

Actually, I think I'm going to keep this open until syntax is set in stone. There's a pretty good chance it will stay as is, but I had some other ideas I wanted to at least consider.

I think what I'd like the most is to have

@concrete struct Foo{T<:Real}
    x::T
    y::Real
    z::AbstractMatrix{T}
end

evaluate to

struct Foo{T<:Real, Ty<:Real, Tz<:AbstractMatrix{T}}
    x::T
    y::Ty
    z::Tz
end

The reason I'd like to have this is I don't like the fact that fields like y::Real don't automatically become concrete when using a macro called @concrete. I feel like it sort of breaks the promise of the macro when we don't evaluate everything as concretely as can be reasonably interpreted. And this seems like a case where it is obvious what should happen.

The downsides of this approach are

1. It's might be a little surprising for someone who actually wanted that field to remain abstractly typed. Although I'm not sure why such a person would be using a @concrete macro in the first place.
2. It's pretty messy to implement. I tried, but ultimately gave up because <: is much easier than trying to guess if the type is abstract given that it can have type variable names from the local scope at the head of the struct definition.

[omicron321]

It's might be a little surprising for someone who actually wanted that field to remain abstractly typed. Although I'm not sure why such a person would be using a @concrete macro in the first place.

i agree with this principle of least astonishment
maybe rename @concrete to something like @derived or else

[ParadaCarleton]

I decided to just go for it. I'm not going to document the feature just yet, because I'm still not 100% on the syntax.

Did you settle on a syntax? I'd like to use this feature but I'm not sure how.

[jonniedie]

Yeah, I'd say it's officially settled on the syntax @willtebbutt suggested. Or at least people (including myself) have been using it for over a year now and I have no reason for/intention on breaking their workflow at this point. You can use it as follows:

@concrete struct Foo
    x<:Real
    y<:AbstractArray
end

Which will expand out to something like

struct Foo{Tx<:Real, Ty<:AbstractArray}
    x::Tx
    y::Ty
end

I'm going to go ahead and close this now.