Should this class be deprecated? No one is using it internally and the superclass is more generalized.

I'd be OK with deprecating this and redirecting people to RenderConstraintsTransformBox.

what do you mean by "selectively enforcing some of its intrinsic sizing rules"?

reworded.

Might be worthwhile to document somewhere in here what this does if child is null.

assert this in the constructor and setter instead of here?

I'd be OK with deprecating this and redirecting people to RenderConstraintsTransformBox.

Isn't this just duplicating behavior of the UnconstrainedBox widget? Can we just link to that one in the docs?

Same with the other two here.

I'll expose the static functions instead of named constructors.

nit: @ goes inside the {

same

Given the type String, presumably debugTransformType also cannot be null? Maybe assert that as well?

This could also just be implemented as a stateless widget now which builds a ConstraintsTransformBox?

Just an idea, let me know what you think:

Make this not required. If it's null, then it just uses the constraints it has as-is.

Maybe that's kind of pointless, but I was thinking it would allow you to get rid of _unmodified in the main PR: https://github.com/flutter/flutter/pull/64615/files#diff-f5f93c879cef9a102adbf148583de9f3d9a05f9678fdcad7bde106f62200bb34R2606

I'll expose the static functions ('unconstrained' etc,.), instead of the named constructors then.

Could this also be achieved with the code below, or am I misunderstanding?

LayoutBuilder(
  builder: (BuildContext context, BoxConstraints constraints) {
    return ConstrainedBox(
      constraints: constraints.copyWith(maxHeight: double.infinity),
      child: const Card(child: Text('Hello World!')),
    );
  },
)

ConstrainedBox is a bit different from ConstraintsTransformBox, as it does not replace the original constraints but adds additional constraints to the original constraints. In this example, if the parent is a SizedBox(height: 50) then in the above example the Card can be as high as it wants but with ConstrainedBox the maxium height is 50. I'll update the example to be more specific.

I really thought that my example here was the same as ConstraintsTransformBox, but I tried it and they are not the same.

So here's a simple example not using anything new:

            Container(
              height: 100,
              color: Colors.red,
              clipBehavior: Clip.none,
              child: ConstrainedBox(
                constraints: BoxConstraints(maxHeight: double.infinity),
                child: Container(
                  height: 200,
                  color: Colors.blue.withOpacity(0.5),
                ),
              ),
            ),

Both Containers are 100px high there. There is no overflow. I would have expected the blue Container to extend outside of the red Container, but I guess I'm wrong about how Flutter does this :)

Now here's a similar thing using ConstraintsTransformBox:

            Container(
              height: 100,
              color: Colors.yellow.withOpacity(0.5),
              child: ConstraintsTransformBox(
                alignment:Alignment.topLeft,
                constraintsTransform: (BoxConstraints constraints) => constraints.copyWith(maxHeight: double.infinity),
                child: Container(
                  height: 200,
                  color: Colors.blue.withOpacity(0.5),
                ),
              ),
            ),

The inner blue Container is able to extend outside of its parent, with an overflow warning.

So I think this makes sense and I understand how this widget produces a unique behavior that doesn't seem to be easily doable with existing widgets 👍

What's the difference between "natural" as you use it here and "intrinsic" as in intrinsicHeight/Width?

Also just out of curiosity, what if the child's intrinsic width or height is larger than the device's screen? Will it actually be able to render that big or will it be constrained by the screen size? (This would be larger than the parent in most normal cases, so it would also give an overflow warning, but I'm curious what would happen.)

Ah I'm using them interchangeably. I'll replace intrinsic with natrual.

I think the child will be rendered as if there was infinite space (given it's not clipped) and will be aligned per its alignment. But yeah if it ends up being larger than the RenderView you'll get a warning (this is a debugging widget in some sense).

I tried this out and for this app:

    MaterialApp(
      home: Scaffold(
        body: ConstraintsTransformBox(
          constraintsTransform: myConstraintsTransform,
          child: Container(
            color: Colors.red,
          ),
        ),
      ),
    );

When myConstraintsTransform is...

• (BoxConstraints constraints) => constraints, the whole screen is red.
• (BoxConstraints constraints) => constraints.copyWith(maxHeight: 10000), the whole screen is red, and there is an overflow warning.
• (BoxConstraints constraints) => constraints.copyWith(maxHeight: double.infinity), the whole screen is empty, no warning.

Should there be an error for that last case with infinite height? Or actually maybe that is the normal behavior when you make the constraints infinite in Flutter.

Container has a LimitedBox which only kicks in when the size is unconstrained. I think what happened was when the maxHeight is unconstrained the LimitedBox will try to become as small as possible so the ColoredBox wrapped inside the LimitedBox is zero-sized (case 3).

Mention the deprecation and what to use instead in the doc above?

intrinsic = natural, as used below?

What do you mean by "during development"? Should this widget not be used in production?

changed to "This widget can be used to ensure some of [child]'s natrual dimensions are honored, and get an early warning otherwise during development. "

Should this return the argument "constraints"? Otherwise its not matching the documentation of being an identity function...

nit: name this _debugKnownTransforms to message that it's only supposed to be used within debug* methods?

This is kinda odd. How about defining UnconstrainedBox as a Stateless widget that builds a ConstraintsTransformBox as a child (composition over inheritance)?

Also link to ConstraintsTransformBox here?

can -> will, it doesn't have a choice, right?

keep these white spaces between properties?

odd extra whitespace?

nit: keep this whitespace?

nit: keep this whietspace?