I could get behind making fields public and treating them as just bundles of data; a description of the shape of a type.

I wonder whether there are any forseeable reasons to keep this internal structure hidden; @ascjones perhaps you have thoughts?

If we do go this route I'd also be tempted to add a #[deprecated(...)] attr to each of the getter functions to encourage people over to just accessing the fields directly (it would be nice ultimately to be consistent and remove the getters in the next major version).

The attr could look something like:

#[deprecated(since = "2.5.0", note = "prefer to access the fields directly; this getter will be removed in the next major version")]

That said I'd have to test where warnings will show for this, and wouldn't want warnings appearing for anybody who is only indirectly using scale-info at the latest version via some other crate (since they couldn't do anything about it).

The other option is to do a major version bump and remove the getters immediately, but that would create more churn..

The other option is to do a major version bump and remove the getters immediately, but that would create more churn

Yep indeed. Either way we pick seems solid and we'll eventually end up removing them (waiting for @ascjones to confirm this).

That being said, we could remove them now and handle the breaking changes individually:

• create a new release with scale-info
• update + release every crate that depends on this in the substrate dependency graph (changes are trivial to modify, although a bit of effort to track everything down)

I'm fine with making these public.

Regarding the getters, probably best to deprecate them for the least disruption, then remove for a 3.0 release.

This looks good to me!

I think that #[deprecated] warnings in sub-dependencies won't trickle up (eg if A depends on B which depends on C, and C uses #[deprecated] on some stuff B is using, then if I compile A I would hope not to see those warnings). I bring this up just because it could be quite noise for anybody transitively depending on scale-info anywhere if this isn't actually the case. Would be good to confirm if possible :)

I had a go locally and created 3 crates in 3 folders seen below. When I runcargo check in temp I see the deprecated warning. Maybe this is different for published crates, or maybe deprecated warnings do bubble up through all crates?

temp:

cargo.toml:

[dependencies]
temp2 = { path = "../temp2" }

lib.rs

pub fn add(left: usize, right: usize) -> usize {
    temp2::add(left, right)
}

temp2

cargo.toml:

[dependencies]
temp3 = { path = "../temp3" }

lib.rs

pub fn add(left: usize, right: usize) -> usize {
    temp3::add(left, right)
}

temp3

lib.rs

#[deprecated]
pub fn add(left: usize, right: usize) -> usize {
    left + right
}

I've had a go at this in paritytech/subxt#879.

What I did there was to point scale-info to this branch in Cargo.toml

[patch.crates-io]
scale-info = { git = "https://github.com/paritytech/scale-info.git", branch = "lexnv/resolve_mut" }

Warnings did appear for all subxt usages across the repo, but after fixing those individually in this commit they went away.

I asked in the reddit and warnings apparently only show up for local crates, not those published to crates.io, so I think all is good :)