# Get long type information for struct definition

**URL:** <https://discourse.julialang.org/t/get-long-type-information-for-struct-definition/123900>\
**Category:** Performance\
**Created:** [December 16, 2024, 7:59pm UTC](https://discourse.julialang.org/t/get-long-type-information-for-struct-definition/123900 "2024-12-16T19:59:13Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [December 17, 2024, 7:13am UTC](https://discourse.julialang.org/t/get-long-type-information-for-struct-definition/123900/6 "2024-12-17T07:13:58Z")

</div>

> [@linwaytin](#):
>
> I really hope julia can support computing type information as the package does.

That’s unfeasible because symbols can refer to different functions in different modules and a generic function can change its behavior and results dynamically, but a type and its instances’ structure _cannot_. As a consequence, those type parameters you’re trying to condense are necessary for adapting to method changes. That massive (and as far as I’m aware, internal) `Extrapolation` type is rooted in many method calls, and as far as the language is aware, any of them can change behavior and result in a different return type of `cubic_spline_interpolation`, even though nobody would do that in practice.

ComputedFieldTypes is no exception, it omits the full type parameters from the constructor methods, but they still must exist and are still printed that way. Here’s an [earlier example](https://discourse.julialang.org/t/simple-compile-time-evaluation-for-struct-types/103326/4). I’m not certain, but I think it is hypothetically possible for unchangeable and pure built-in functions like `<:` to allow very limited field type computation.

Let’s simplify your example. You effectively want to do something like:

```julia
julia> struct Foo{T}
         vec::Vector{T} # longer to type than T
       end

julia> Foo([1])
Foo{Int64}([1])

```

but with an instantiating method instead of explicitly typing the type out, like

```julia
struct Foo{T}
  vec::typeof(ones(T, 1)) # not valid code
end

```

But this is impossible because `Foo{MyType}` becomes several concrete types with different `vec` field types depending on how I redefine `Base.ones(::Type{MyType}, dims)` (don’t do this in practice). The only way for `Foo{MyType}` to be a valid type is to have `vec::Any` to accommodate all possible results of the field type computation. Going back to your example, `itp::Any` is necessary to adapt to various `cubic_spline_interpolate` calls in practice because the concrete type of `itp` also depended on the `0:0.1:0.2` input; even if we pretended methods were set in stone so parameters could be condensed, `T` for the `zeros` input was not enough. You can make a `Foo` constructor that computes `T` from `itp` before calling `Foo{T}(itp, args...)`.

---

_[View the full topic](https://discourse.julialang.org/t/get-long-type-information-for-struct-definition/123900)._