[cfe-dev] Impending initialization rewrite

Douglas Gregor dgregor at apple.com
Mon Nov 30 08:10:27 PST 2009


On Nov 30, 2009, at 8:09 AM, Sebastian Redl wrote:

> 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.


I missed that consumer of initialization... I'll look there, too.  
Thanks!

	- Doug



More information about the cfe-dev mailing list