> On Jul 28, 2017, at 11:13 AM, Maciej Stachowiak <m...@apple.com> wrote: > > > >> On Jul 28, 2017, at 10:58 AM, Sam Weinig <wei...@apple.com >> <mailto:wei...@apple.com>> wrote: >> >> >> >>> On Jul 28, 2017, at 10:31 AM, JF Bastien <jfbast...@apple.com >>> <mailto:jfbast...@apple.com>> wrote: >>> >>> >>> >>>> On Jul 28, 2017, at 10:29, Sam Weinig <wei...@apple.com >>>> <mailto:wei...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
