Ãvar ArnfjÃrà Bjarmason wrote: > Thanks for this. This was raised earlier in the discussion for this > series (by you, IIRC). I've considered it, and while I see your point > (type safety = good) I think I like my way of doing it better. > > The _() macro/function is usually a macro and not a function. The good > thing about this is that I can prove that it's a no-op on all > compilers, whereas if it's an inline function (stupid) compilers will > actually make it into a function, which'll result in overhead, > which'll mean I can't advertise this series as a "no-op" anymore. I hope we don't support (meaning "worry about") such stupid compilers? At least I haven't seen this being a consideration in deciding whether to split out inline functions in the past. Perl is much more portable than git, and that seems perfectly fine to me. > So that's why I didn't do it. But if everyone else feels strongly > about it I'll change my mind, I don't care *that* much about it, but > I'd prefer a macro. I think it's perfectly possible there's some aesthetic or functional reason to make this a macro instead of a function, and that would be fine with me. On the other hand, if there's no reason, then I do feel strongly about it, fwiw. New code should set a good example. Thanks for your thoughtfulness. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html