[cfe-dev] Impending initialization rewrite

Sebastian Redl sebastian.redl at getdesigned.at
Mon Nov 30 08:09:17 PST 2009


Douglas Gregor wrote:
> Interface:
>
> The main initialization code will have three entry points:
>
> 	TryInitialization) determines whether an object or reference can be initialized from a given set of expressions, taking into account the kind of initialization (direct, copy, value, etc.), target type, source expression, etc. The result of this routine will be some indicator of success/failure and an InitializationSequence which, like ImplicitConversionSequence, will describe the steps needed to perform the initialization. TryInitialization will never emit diagnostics nor build any permanent ASTs.
>
> 	PerformInitialization) performs the initialization of an object or reference given an InitializationSequence, building appropriate ASTs and performing checking that had to be delayed because it isn't part of overloading (e.g., binding a non-const reference to a bit-field).
>
> 	DiagnoseInitialization) emits diagnostics for a failed initialization, where TryInitialization could not produce a valid initialization sequence. The key here is reusability: we want DiagnoseInitialization to be used both by the obvious clients (variable initialization, base/member initialization, casts) and also for overload resolution (e.g., to specify precisely why a given overload candidate failed to match).
>
> Any questions, comments, or advice would be appreciated!
>   
I love it.

I believe there are some comments in the static_cast code that address a
problem with diagnostics for the "explicit implicit conversion" case. We
should make sure that DiagnoseInitialization is suitable for this purpose.

Sebastian



More information about the cfe-dev mailing list