Mark Dickinson

A few points from discussion in another channel: To summarize the issue: we have a trait where the validity of the value is constrained by the value of other traits....

After #1531, #1532, #1536 and #1539, the following `TraitType` subclasses still make use of the type inference. (This list may not be exhaustive - it only covers the trait types...

Yes, I need to look into that. I find it hard to believe that we never access the default value for an `Array` trait within the test suite.

Ah, `AbstractArray` overrides `get_default_value`, so it never encounters that code. So there's nothing to do for `AbstractArray` and its subclasses.

The other notable oddity is `Either`, which overrides the `as_ctrait` method, so also doesn't invoke `TraitType.get_default_value`. (It's possible that `Either` shouldn't be a `TraitType` subclass at all.)

`Constant` is dealt with in #1540; `Readonly` is addressed in an updated version of #1531. That just leaves `Event`, `Disallow`, and `Delegate` and its subclasses. As another check, here are...

Bumping the remainder of this for 6.4.0

This is still high priority, but it's not going to make it into the 6.3.0 release.

This is probably low priority to fix for the existing machinery; I don't know of any actual use-cases for `remove_trait`. We have various pieces of code where we build up...

> I don't know of any actual use-cases for `remove_trait` Scratch that. There are uses in `blockcanvas` and `mayavi`, as well as in the `rkern` directory in enthought/internal: https://github.com/enthought/internal/blob/41e1b5d70200e2dc088f175dbc946f75689822ef/rkern/prosper/widgets.py#L274