diff options
| author | kaizhangNV <149626564+kaizhangNV@users.noreply.github.com> | 2025-02-05 12:37:03 -0600 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-02-05 10:37:03 -0800 |
| commit | 9ec6b91686b651d959fd9ffbec283845bd725dd6 (patch) | |
| tree | 2c48202cb04b76e5ddcb274be35529378ddf8f31 /docs | |
| parent | 4b350645042b8e8fbdad19784ee745d11c7bc616 (diff) | |
Feature/initialize list side branch (#6058)
* SP004: implement initialize list translation to ctor
- We synthesize a member-wise constructor for each struct follow
the rules described in SP004.
- Add logic to translate the initialize list to constructor invoke
- Add cuda-host decoration for the synthesized constructor
- Remove the default constructor when we have a valid member init constructor
- Disable -zero-initialize option, will re-implement it in followup (#6109).
- Fix the overload lookup issue
When creating invoke expression for ctor, we need to call
ResolveInvoke() to find us the best candidates, however
the existing lookup logic could find us the base constructor
for child struct, we should eliminate this case by providing
the LookupOptions::IgnoreInheritance to lookup, this requires
us to create a subcontext on SemanticsVisitor to indicate that
we only want to use this option on looking the constructor.
- Do not implicit initialize a struct that doesn't have explicit default
constructor.
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/proposals/004-initialization.md | 38 |
1 files changed, 36 insertions, 2 deletions
diff --git a/docs/proposals/004-initialization.md b/docs/proposals/004-initialization.md index 6a41cab23..9ce143866 100644 --- a/docs/proposals/004-initialization.md +++ b/docs/proposals/004-initialization.md @@ -129,6 +129,39 @@ MyType x = MyType(y); // equivalent to `x = y`. The compiler will attempt to resolve all type casts using type coercion rules, if that failed, will fall back to resolve it as a constructor call. +### Inheritance Initialization +For derived structs, slang will synthesized the constructor by bringing the parameters from the base struct's constructor if the base struct also has a synthesized constructor. For example: +```csharp +struct Base +{ + int x; + // compiler synthesizes: + // __init(int x) { ... } +} +struct Derived : Base +{ + int y; + // compiler synthesizes: + // __init(int x, int y) { ... } +} +``` + +However, if the base struct has explicit ctors, the compiler will not synthesize a constructor for the derived struct. +For example, given +```csharp +struct Base { int x; __init(int x) { this.x = x; } } +struct Derived : Base { int y;} +``` +The compiler will not synthesize a constructor for `Derived`, and the following code will fail to compile: +```csharp + +Derived d = {1}; // error, no matching ctor. +Derived d = {1, 2}; // error, no matching ctor. +Derived d = Derived(1); // error, no matching ctor. +Derived d = Derived(1, 2); // error, no matching ctor. +``` + + ### Initialization List Slang allows initialization of a variable by assigning it with an initialization list. @@ -167,7 +200,8 @@ If the above code passes type check, then it will be used as the way to initiali If the above code does not pass type check, and if there is only one constructor for`MyType` that is synthesized as described in the previous section (and therefore marked as `[Synthesized]`, Slang continues to check if `S` meets the standard of a "legacy C-style struct` type. A type is a "legacy C-Style struct" if all of the following conditions are met: -- It is a user-defined struct type or a basic scalar, vector or matrix type, e.g. `int`, `float4x4`. +- It is a user-defined struct type or an enum, a basic scalar, vector or matrix type, e.g. `int`, `float4x4`. +- It does not inherit from any other types. - It does not contain any explicit constructors defined by the user. - All its members have the same visibility as the type itself. - All its members are legacy C-Style structs or arrays of legacy C-style structs. @@ -405,4 +439,4 @@ Alternatives Considered One important decision point is whether or not Slang should allow variables to be left in uninitialized state after its declaration as it is allowed in C++. In contrast, C# forces everything to be default initialized at its declaration site, which come at the cost of incurring the burden to developers to come up with a way to define the default value for each type. Our opinion is we want to allow things as uninitialized, and to have the compiler validation checks to inform -the developer something is wrong if they try to use a variable in uninitialized state. We believe it is desirable to tell the developer what's wrong instead of using a heavyweight mechanism to ensure everything is initialized at declaration sites, which can have non-trivial performance consequences for GPU programs, especially when the variable is declared in groupshared memory.
\ No newline at end of file +the developer something is wrong if they try to use a variable in uninitialized state. We believe it is desirable to tell the developer what's wrong instead of using a heavyweight mechanism to ensure everything is initialized at declaration sites, which can have non-trivial performance consequences for GPU programs, especially when the variable is declared in groupshared memory. |
