Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ergonomics of zstring usage #1821

Closed
JordanMaples opened this issue Aug 18, 2021 · 8 comments
Closed

ergonomics of zstring usage #1821

JordanMaples opened this issue Aug 18, 2021 · 8 comments
Assignees

Comments

@JordanMaples
Copy link

microsoft/GSL#992

Microsoft's gsl::zstring requires and empty angle brackets for use due to the Extent template parameter in the definitions of basic_zstring

template <typename CharT, std::size_t Extent = dynamic_extent>
using basic_zstring = CharT*;

template <std::size_t Extent = dynamic_extent>
using zstring = basic_zstring<char, Extent>;

Examples of zstring and friends in the Core Guidelines implies that the zstring should be able to be instantiated without needing trailing angle brackets. Should Microsoft/GSL's definitions of basic_zstring and all derived definitions remove the Extent parameter

@hsutter
Copy link
Contributor

hsutter commented Aug 19, 2021

Editors call: In C++20, could this be done with a deduction guide instead of removing the parameter?

@JohelEGP
Copy link
Contributor

No. That only works when initializing a variable. In the first example, it already needs <>

void lower(zstring s)
{
    for (int i = 0; i < strlen(s); ++i) s[i] = tolower(s[i]);
}

@hsutter
Copy link
Contributor

hsutter commented Aug 19, 2021

@JohelEGP that was a limitation in C++17, but C++20 added support for deduction guides in type aliases:
- http://eel.is/c++draft/over.match.class.deduct#2
- http://open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1814r0.html

(Disclaimer: No worries, we had to look this up too! According to cppreference.com, GCC and MSVC have implemented this feature, but Clang has not yet. It's still pretty new.)

So the question above was to verify with @JordanMaples whether this would solve the problem -- and even if the answer is yes, then next we would have to decide whether to accept the C++20 dependency since both the Guidelines and the Microsoft GSL implementation don't generally cover/depend on C++20 yet.

@JohelEGP
Copy link
Contributor

It doesn't work: https://godbolt.org/z/esYe68Ysn.

@JohelEGP
Copy link
Contributor

My understanding is that this is asking to make zstring not an alias template, but a type alias. Because the guidelines use zstring without <> in contexts where CTAD doesn't take place, that wouldn't be enough.

@hsutter
Copy link
Contributor

hsutter commented Sep 30, 2021

Editors call: Thanks. Do we have data about whether the extra parameter is used in the field?

@hsutter
Copy link
Contributor

hsutter commented Sep 30, 2021

Relaying from the GSL repo, Jordan reports:

I ran a quick search on Github for zstring and czstring to see how users are using *zstring and found that the majority of uses just have empty angle brackets. I came across a couple uses where the user does specify an extent, here is one such case:
https://github.com/luncliff/coroutine/search?q=zstring. Most of the other hits that I found were clones or copies of this coroutine library.

@hsutter
Copy link
Contributor

hsutter commented Oct 14, 2021

Editors call: Thanks. We agree that the convenience alias should be convenient and doesn't need the extra template parameter, and the Guidelines already show zstring is intended to be used without <> -- users who want to customize either template argument can use basic_zstring directly.

So please change this

template <std::size_t Extent = dynamic_extent>
using zstring = basic_zstring<char, Extent>;

to just this

using zstring = basic_zstring;

which conforms to the usage in the Guidelines. We understand that's a breaking change for your users to remove the <>. But this is what the Guidelines intended.

@hsutter hsutter closed this as completed Oct 14, 2021
@hsutter hsutter self-assigned this Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants