RESOLVED MOVED 178978
[WSL] Synthesize constructors for structs
https://bugs.webkit.org/show_bug.cgi?id=178978
Summary [WSL] Synthesize constructors for structs
Myles C. Maxfield
Reported 2017-10-27 22:08:31 PDT
This will let you put pointers inside structs.
Attachments
Patch (11.57 KB, patch)
2017-10-28 11:36 PDT, Myles C. Maxfield
no flags
Patch (16.65 KB, patch)
2017-10-28 15:04 PDT, Myles C. Maxfield
mmaxfield: review-
Myles C. Maxfield
Comment 1 2017-10-28 08:55:09 PDT
Object literals are a little tricky because of something like this: struct Foo { int x; } struct Bar { uint x; } void func(Foo f) { ... } void func(Bar f) { ... } func({3}); This is a case where the contents of the object literal will participate in function overload resolution. However, if the goal is simply to be able to specify the contents of a struct in a variable initializer, we don't actually need object literals; we can just synthesize a constructor for each struct which contains members for each field. This means that the author will have to state which type they are constructing, which means that the contents are not considered when performing function overload resolution (and function overload resolution is unchanged. For arrays, you can't put a pointer or an array reference anywhere into an array, which means that variable initializers are no more powerful than regular assignments; therefore, we don't really need array literals. Retitling.
Myles C. Maxfield
Comment 2 2017-10-28 08:58:50 PDT
We already synthesize field accesses to structs; adding synthesized constructors shouldn't be too difficult.
Myles C. Maxfield
Comment 3 2017-10-28 11:36:34 PDT
Myles C. Maxfield
Comment 4 2017-10-28 15:04:28 PDT
Filip Pizlo
Comment 5 2017-10-30 13:56:59 PDT
Comment on attachment 325267 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=325267&action=review > Tools/ChangeLog:12 > + Similar to how we synthesize field accesses, we can also synthesize constructors > + which initialize each member of the struct. This is more powerful than making > + the author write these constructors, because, in logical mode, the native > + implementation can assign to pointer fields in the struct, which the author can't > + do. I think that the more canonically-C++-like way to solve this problem is to just add support for struct/array literals. Like the NullLiteral and the GenericLiteral (that creates IntLiteral and friends), this will have a corresponding type variable, which will only unify with either arrays or structs. You might as well make this sensible from day one. For example, {1, 2, 3} should unify with either T[3] where T unified with 1, 2, and 3; or a struct with three fields, whose types (T, U, and V) unify with the values (1, 2, 3). But {f = 4, g = 6} should only unify with structs that have exactly "f" and "g" as their fields (in any order), and their types unify with 4, 6.
Myles C. Maxfield
Comment 6 2018-10-13 19:17:40 PDT
Note You need to log in before you can comment on or make changes to this bug.