commit bbde22993476d5265baadba022be35852c5101d7
author Googler <noreply@google.com> Thu Nov 21 12:51:51 2019 -0800
committer Copybara-Service <copybara-worker@google.com> Thu Nov 21 12:54:00 2019 -0800
tree 8b599e673293f674150557dbf716f2fe381dde70
parent 9257870bf9376ea2ca101e6bb160577f7114585b

bazel syntax: simplify SkylarkNestedSet type rules

Previously, StarlarkNestedSet would compute the "intersection"
of the existing type and the type of each new element.
Now, it checks that they match exactly.

Already in Starlark, the expression depset([1, 2, "three"]) fails
because the set commits to integers after the first value
and rejects the string because their intersection is "object".
I could not find any place where the intersection was interesting.
One might expect tuple + list to intersect to sequence, but
lists are not valid elements. (The approach of inferring "the"
type from a value seems problematic. Ideally all SkylarkNestedSets
would have their types determined explicitly.)

The check that rejects dicts and lists is now done by checkValidDictKey,
just like in Dict. (This avoids another call to intersection).
The real requirement is that values are hashable, not immutable.

In SkylarkType:
- eliminate the only external uses of canBeCastTo and getType.
- eliminate the STRING_PAIR concept. It seems a little arbitrary:
  just because the first element is a pair doesn't mean all elements
  need be tuples of length 2.
- lock down nearly all of the API, which I plan to redesign
  to solve two problems:

  1) StarlarkType values should act as well-typed converter functions
     for arbitrary values. Users should be able to write:
       List<String> list = convert(myvar, stringListType, "myvar")
     and get a correctly typed result or a high-quality error such as
     "for myvar[3]: got int, want string".

  2) StarlarkType should enable deep checks, unlike Class checks
     which are shallow though shallow checks should be possible too:
       SkylarkType<List<?>> ANY_LIST
     would not visit the list elements.

  A SkylarkType would thus act like a "reified generic" type descriptor.

PiperOrigin-RevId: 281811861