Remove non-nullable restriction from InputT, StateT, and RenderingT. #334
Conversation
Making the rendering type non-nullable doesn't add any inherent value or safety. There may be workflows that want to define a nullable rendering type, so we should let them. Workflows that define their rendering types as non-nullable still get all the null safety they expect.
Making the input type non-nullable doesn't add any inherent value or safety. There may be workflows that want to define a nullable input type, so we should let them. Workflows that define their input types to be non-nullable still get all the null safety they expect.
Making the state type non-nullable doesn't add any inherent value or safety. There may be workflows that want to define a nullable state type, so we should let them. Workflows that define their state types to be non-nullable still get all the null safety they expect.
|
Was there a specific issue that drove this change? And if nullability is okay now, why isn't it okay for |
I was working on the legacy integration, and it would have been convenient to use
Also, |
Making these types non-nullable doesn't add any inherent value or safety. There may be workflows
that want to define nullable types, so we should let them. Workflows that define their types to be non-nullable still get all the null safety they expect.