[webkit-dev] Using "auto <function()> -> returnType" breaks prepare-ChangeLog
Sam Weinig
weinig at apple.com
Fri Jul 28 11:25:18 PDT 2017
> On Jul 28, 2017, at 11:13 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>
>
>> On Jul 28, 2017, at 10:58 AM, Sam Weinig <weinig at apple.com <mailto:weinig at apple.com>> wrote:
>>
>>
>>
>>> On Jul 28, 2017, at 10:31 AM, JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>>>
>>>
>>>
>>>> On Jul 28, 2017, at 10:29, Sam Weinig <weinig at apple.com <mailto:weinig at apple.com>> wrote:
>>>>
>>>> For some generic programming, this form can be dramatically shorter:
>>>>
>>>> e.g.
>>>>
>>>> template<typename KeyArg, typename MappedArg, typename HashArg, typename KeyTraitsArg, typename MappedTraitsArg>
>>>> template<typename K, typename V>
>>>> ALWAYS_INLINE auto HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
>>>> {
>>>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, HashFunctions>>(std::forward<K>(key), std::forward<V>(value));
>>>> }
>>>>
>>>> vs.
>>>>
>>>> template<typename KeyArg, typename MappedArg, typename HashArg, typename KeyTraitsArg, typename MappedTraitsArg>
>>>> template<typename K, typename V>
>>>> ALWAYS_INLINE typename HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, MappedTraitsArg>::AddResult HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, MappedTraitsArg>::inlineAdd(K&& key, V&& value)
>>>> {
>>>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, HashFunctions>>(std::forward<K>(key), std::forward<V>(value));
>>>> }
>>>>
>>>> It is also the only format available for lambdas, so people are probably getting used to it.
>>>>
>>>> Not sure it’s worth it to avoid it.
>>>
>>> Agreed.
>>>
>>> That being said, I’m not volunteering to fix the parser’s handling of lambdas. At that point we should really consider using clang’s AST.
>>
>> I absolutely agree. For this and the style checker, it’s probably time to migrate to clang tooling.
>
> Using a real parser is probably a good idea at some point.
>
> But I am not sure it's necessary for prepare-ChangeLog to know about the boundaries for lambdas. It's goal is to list all named functions that the local changes have modified. For modifications to the body or signature of a lambda, naming the function that contains the lambda is probably the most useful option. I think that already works as expected.
>
I didn’t mean to imply that we should have lambdas in ChangeLogs, only that people were probably getting used to that syntax. Sorry for the confusion.
-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170728/248b281f/attachment.html>
More information about the webkit-dev
mailing list