Allow implicit conversion of brace-lists to type list

[ChrisDodd]

An explicit list type has been in the spec for awhile, but p4c was requiring explicit casts on {}-lists to match them to list typed thing in type unification.

This small change allow unification of {} lists with type list without an explicit cast.

[vlstill]

I don't think this adheres to the current language spec. If I look correctly, this would essentially be an implicit cast from a tuple expression to a list expression (P4 lists should be syntactically written as (list<T>){...} while {...} is a tuple). The spec does not define such casts in https://p4.org/p4-spec/docs/P4-16-v1.2.4.html#sec-casts.

I was tempted to suggest adding this to the spec, but on closer thought I don't think it would be a great addition. If a heterogeneous tuple was passed to a function that expects a list, the typing errors could be quite weird. Also implicit casts in general tend to create a lot of problems in languages that use them liberally (like C++) so I am quite glad P4 is quite restrictive in their use.

There are probably not enough brace characters to give different syntax to tuples, lists, structs, ... One improvement could be to allow syntax like list{a, b, c} (or (list){a, b, c}) as a shorthand for (list<T>){a, b, c} where T is the type of a.

[vlstill]

Avoid double-search:

Suggested change

	if (elTypes.count(t)) continue;
	elTypes.insert(t);
	if (!elTypes.insert(t).second) continue;

[ChrisDodd]

The spec doesn't really say what a brace enclosed list by itself is, so allowing it to be implicitly converted to a tuple or a struct or a header type, but not implicitly converted to a list seems inconsistent.

Most programmers coming from a C background will expect to be able to use brace-enclosed lists to initialize both array-like things and a struct-like things. Its also somewhat painful to need an explicit cast here when it is clear from context what is going on.

[vlstill]

The spec doesn't really say what a brace enclosed list by itself is, so allowing it to be implicitly converted to a tuple or a struct or a header type, but not implicitly converted to a list seems inconsistent.

Could be, but in that case we should update the spec first.

Most programmers coming from a C background will expect to be able to use brace-enclosed lists to initialize both array-like things and a struct-like things. Its also somewhat painful to need an explicit cast here when it is clear from context what is going on.

C is not exactly known for a nice type system. But you have a point here, many languages have some kind of initializer syntax which can be many different things based on context. But the rules should be precisely defined by the spec -- are there cases where a tuple-like initializer can be passed to an argument with parametric types? Are there cases where we would need to give priority or reject the cast because there are multiple variants? The latter probably not since we don't have type-based overloading if I look correctly.

[fruffy]

Should we create a spec issues here?