[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