>nothing silently wins.
Fantastic! Never change this.
People will complain. These people also prefer type unsafe languages. Hold fast.
>nothing silently wins.
Fantastic! Never change this.
People will complain. These people also prefer type unsafe languages. Hold fast.
Thanks! My concern was that a resolver making decisions "to be helpful" could become surprising or frustrating.
For example, if you ask for edges to pass "between C and D", but those two nodes sit diagonally, the gap you are asking for might be the vertical channel or horizontal channel between them. So instead of guessing for you, it will tell you of the ambiguity and let you spell out what you want.
I think this should be a warning. Fighting the compiler when trying to draw a diagram is maybe a bit too much...
That's something I'm trying to keep in mind for sure. If someone said something that couldn't be rendered, instead of surprising you with the tool deciding for you, that might be where the error comes in rather than a warning. The trivial example would be you said B is both "left of A" and "right of A".
But, I could see the other extreme where if you said "I want an edge going from the left side of A to the right side of B", you wouldn't want the tool to say "well, you didn't specify if I should go above A or below A, so I refuse to do anything". That could be super annoying. A sensible default that you can override would probably be more ergonomic there.
Is that sorta the way you'd think about it too? Or would you be more in favor of greater permissiveness, where the tool prefers warning even in contradictory scenarios?