I don't think that this has ever been a topic in its own right (although it has been mentioned before)

I'd like to consider an operator to load a list:

list <<< "One" <<< "Two" <<< "Three"

This would be used in construction-with-blocks too:

FwtContainer {
  title = "Foo"
  <<< Label { ... }
}

I believe it makes the constructor case much more understandable conceptually, and would be a useful operator in general.

(Note that I've separated this from the bigger constructor validation debate for now)

I am not sure I understand the proposal - is this some sort of cons operator?

Why is this better than what you can do today:

list.add("One").add("Two").add("Three")

list.addAll(["One", "Two", "Three"])

I prefer named methods too adding new operators - that is down the dark path towards operator diarrhea.

Other threads have mentioned using a comma after elements added in with-blocks that implicitly call add(). This is a proposal to make that explicit.

An operator like this is relatively common in other languages, and works as follows:

list <<< "One" <<< "Two" <<< "Three"
// same as
list.add("One").add("Two").add("Three")

My concern is with new methods in classes changing the meaning of implicit adds, which is one of the reasons for the override keyword. But if that's deemed low risk, then so be it.

Well I think it is definitely worth exploring what exactly the risk is to make an informed decision. Here is the only case I can think of which would cause a problem:

class Foo
{
   Void add(Str b)
}

class Baz
{
   Foo something() { return Foo { bar } }
   Bar bar() { return Bar() }
}

This code will work find and add the result of bar() to the Foo instance. But if later I add a Foo.bar method which with exact same signature, then the meaning of the Foo { bar } would change.

That is the sort of thing dynamically languages deal with all the time. Is it something Fan should try to statically catch? I think it would be nice, but then again I'm not sure it worth extra syntax.

My concern is that it works before and "works" after, and the change in meaning is not obvious to whoever changes the Foo class. Usually, it feels "safe" to add methods. Still, I doubt this would be an everyday problem. Just an occasional "why's it suddenly broken when it said it was backwards compatible?" failure. And not all dynamic language concerns hit this, but catch-all cases (which do often exist when people get clever) run risks of this sort. Might not be a big deal. Don't know.