> On Jul 28, 2017, at 10:31 AM, JF Bastien <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. - Sam > > >> - Sam >> >>> On Jul 27, 2017, at 11:06 PM, Brady Eidson <beid...@apple.com >>> <mailto:beid...@apple.com>> wrote: >>> >>> I just noticed this tonight. When a change is made to one of these >>> functions, prepare-ChangeLog doesn't log the functions that changed. >>> >>> I have a question and a request. >>> >>> Question: >>> >>> The functions in question where I noticed this: >>> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> >>> ExceptionType >>> >>> Would normally be written as: >>> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const >>> ResourceError& error) >>> >>> Is there some actual value to using this syntax other than… being >>> syntactically different, and being just a little shorter? >>> >>> Request: >>> >>> Until we fix prepare-ChangeLog, and unless there is some great advantage to >>> this syntax that I'm not aware of… it's hold off on using it more. >>> >>> Thanks, >>> ~Brady >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
