Davy Cats

Maybe a bit of a side track this, but perhaps implementing an `import X from Y` type of syntax would aid in avoiding these types of scenarios. --- Personally, I...

I strongly agree with @patmagee here, names should indicate what the value of the variable represents and types should *only* indicate how they can be used. If your naming relies...

Adding test cases is a great idea. But there may be some cases where it will be hard to write tests that actually test the spec. For example, the import...

I don't think this should be a validation error. When the workflow input doesn't have a value then no value is given to the call's input and, thus, the default...

>supplying a null to an input with a default should be possible. ~~Isn't this why the `None` literal was added in 1.1?~~ Nevermind, I think you're correct. Optional inputs would...

I wouldn't strictly oppose to having a `select_any` function. However, I would strongly oppose to it returning a "randomly selected element", since that would be quite bad for reproducibility. If...

@rhpvorderman Are you suggesting to add some method to resort to a task's/workflow's default? Like a function which will cause the input to be omitted if the value given is...

Just to keep things simple for the user, I would say forbidding any and all name collisions would be preferable.

I can definitely see some cases where something like this would be useful, indexes being one obvious example. I'm wondering whether it would not be an option to simply allow...

Since this would be an extension of Struct, I image you would still have to explicitly reference the base. Structs can hold multiple (non-inferred) values after all: ```wdl struct Income...