It doesn't seem like we get much value from const in these struct chains, and it introduces some complexity - every chained struct needs to match the mutability of its root struct, which means they can't be mixed. Right now we have "in", "out", and "inout" (#260) struct chains; we could imagine a situation where we need to attach a new "inout" non-root struct to an "in" struct but can't, and it becomes kludgy.
Doing this would obsolete #376, and allow us to defer the decision from #261 about whether to mix inputs and outputs in the same struct chain (also potentially reducing the number of version 2s of APIs we need if we don't do #216 right now). Loosely affects #264 as well, see there.
It doesn't seem like we get much value from
const
in these struct chains, and it introduces some complexity - every chained struct needs to match the mutability of its root struct, which means they can't be mixed. Right now we have "in", "out", and "inout" (#260) struct chains; we could imagine a situation where we need to attach a new "inout" non-root struct to an "in" struct but can't, and it becomes kludgy.Doing this would obsolete #376, and allow us to defer the decision from #261 about whether to mix inputs and outputs in the same struct chain (also potentially reducing the number of version
2
s of APIs we need if we don't do #216 right now). Loosely affects #264 as well, see there.