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.
- Sam
> On Jul 27, 2017, at 11:06 PM, Brady Eidson <[email protected]> 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
> [email protected]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev