Rather than contribute these to Abseil, we might want to reconsider our use of the chrono_literals. While there's no question that 123_us reads better than microseconds(123), there's a cost associated with using these non-standard (i.e., not from std::chrono) literals. The costs that I see are:

Requires another #include / dep
Requires the use of a using directive, which is not advised for a variety of reasons... OR
Requires strange-looking and verbose using declarations, like using ::google::cloud::testing_utils::chrono_literals::operator"" _ms; (NOTE: The space before the underscore is required in gcc 4.8).

For example:

using ::google::cloud::testing_util::chrono_literals::operator"" _ms;
using ::google::cloud::testing_util::chrono_literals::operator"" _us;
...
  Foo(123_ms + 456_us);

The alternative is

Include <chrono>, which should be included anyway if you're using durations.
Normal/short using declarations.
In C++14, we could use a using directive as is advised by the C++ standard, which is akin to pulling those literals into the global namespace, but that may an exception to the rule since it's advised by the C++ standard. ??? Dunno. We'll decide that when we can use C++14.

For example:

using ::std::chrono::milliseconds;
using ::std::chrono::microseconds;
...
  Foo(milliseconds(123) + microseconds(456));

I think I have a slight preference for directly using chrono rather than our own custom literals, BUT I could easily be convinced to keep our chrono literals because of the succinct call sites they enable.

I'd really like to hear others' thoughts.

Summons @coryan @devbww

Submit bigtable::chrono_literals to abseil.io for consideration #109

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions