[Blocked] Check unique default before using the value

[ying-jeanne]

fixes #15

[sdboyer]

nit: please use keywords - e.g. "fixes #15" - so that the merging of the PR will auto-close the issue. Or, if it doesn't completely address the issue and therefore shouldn't close it, just a "relates to #15" is good. Having the bare issue number is a bit ambiguous.

[sdboyer]

Let's add a test case to ensure that when multiple defaults arise as a result of unification, this logic still catches it. (It seems unlikely that anyone adds multiple defaults on purpose, so this is actually the case that's most important to check for.)

[ying-jeanne]

Let's add a test case to ensure that when multiple defaults arise as a result of unification, this logic still catches it. (It seems unlikely that anyone adds multiple defaults on purpose, so this is actually the case that's most important to check for.)

I can write some example as I understand, it would be nice if we can define a use case together for the real issue, It is probably nice to define use cases when write a user story, TDD would save us some time :).

[ying-jeanne]

this is making sense and erring out now

[ying-jeanne]

currently

AType: *4 | int @cuetsy(kind="type")
Foo: {
  Baz: AType | *7
} @cuetsy(kind="interface")

doesn't error but

AType: *4 | int @cuetsy(kind="type")
BType: *7 | int @cuetsy(kind="type")
Foo: {
  Baz: AType | BType
} @cuetsy(kind="interface")

error out correctly, a tad confusing

[ying-jeanne]

the snippet for the use cases: https://github.com/ying-jeanne/cue_test_cases/blob/bf84db6edba61d3479838967d7445f1775393fc3/main.go

a ticket opened on cue-lang because the expr() behaves weirdly cue-lang/cue#1245

[sdboyer]

wording nit:

Suggested change

	This would be the typical cases we should fail, since Bar is refereced to a type with default
	This would be the typical cases we should fail, since Bar references a type with a default

[sdboyer]

The error message should print out the defaults, to improve failure locality (the cost of mapping a failure to a particular place in code). Ideally, it'd even emit line numbers, like native CUE errors do, but that's more than we need to worry about right now.

[sdboyer]

debug output needs removal

[sdboyer]

Same as other comment, print out the conflicting default values in the error message

[sdboyer]

This is a really interesting question! It should probably be a comment in the PR, or even its own issue, rather than hiding it in an actual committed file, i think.

My intuition is that, first and foremost, we have to follow the constraints imposed by TypeScript's own rules. From there, we should do the least magical thing possible. Given that, my initial thought is to allow this, as:

export enum AOrEnum: {
  Foo: 'foo',
  Bar: 'bar',
  Baz: 'baz'
}

export interface Foo {
  Bar: AOrEnum | "ohai"
}

export const defaultFoo: Foo = {
  Bar: "ohai"
}

At first, this seemed reasonable, because of what i felt i could infer about authorial intent:

1. There's an author of AOrEnum, who expressed the intent that the default value of their type be baz
2. There's an author of Foo, who is (clearly) directly aware of AOrEnum, as they wrote some text explicitly referencing it.
3. Foo's author, being ostensibly aware of AOrEnum, is choosing to supersede the default of baz with ohai.

However, going through this exercise led me to realize that this case is narrow and circumstantial, not based on generalizable principles of the sort people can reason about. That's because we're bumping into fundamental differences in the models on which CUE and TS are based:

1. Defaults are a native concept in CUE that authors must deal with; no such concept exists in TS
2. The primitive kinds in the languages are simply different (disjunction semantics in CUE; existence of enums in TS)
3. While both TS and CUE are mostly structurally typed, which generally it possible to flow types through the system more freely than if names must strictly align, we're (necessarily) making that harder by trying to snapshot bits of the system to translate from CUE to TS, without ever being able to guarantee that we have the whole type graph to examine for completeness or correctness

i don't know what our good answers are here, yet, but the above sort of reasoning makes me reasonably sure there simply aren't any, and we shouldn't waste time or effort searching for them. Instead, we should be very conservative in what we support, erroring aggressively when the slightest bit of ambiguity arises about how to e.g. handle a default or flow an enum into an interface, and then consider opening up further when use cases present themselves.

That's still not a clear, categorical rule we can apply easily, but...well, it's a general basis for saying no and constraining scope, which is usually a safe place to be.

[sdboyer]

All that said, it's worth noting that CUE seems to follow the same logic about user intent/awareness that i originally ran with - see this playground, and note that C has a single default, but D does not. Which is...actually really interesting, and potentially useful.