added a test helper to test each type for having the expected default operations.

[jnyfah]

Pull Request Checklist

Please leverage this checklist as a reminder to address commonly occurring feedback when submitting a pull request to make sure your PR can be reviewed quickly:

See the detailed list in the contributing guide.

• C++ Guidelines
• Doxygen docs
• Unit tests
• No unwanted commits/changes
• Descriptive title/description
  • PR is single purpose
  • Related issue listed
• Comments in source
• No typos
• Update changelog
• Not work-in-progress
• External references or docs updated
• Self review of PR done
• Any breaking changes?

[github-actions]

Thank you for your contribution @jnyfah! We will review the pull request and get back to you soon.

[jnyfah]

@antkmsft Thank you for your help in clarifying this issue for me

I have added a test helper class that checks for the expected default operations for each type, but I'm not sure if I have placed the helper class in the right location and I am also running into some issues with the clang compiler. Specifically, I'm getting undefined reference errors for the type traits.

Could you take a look and let me know if you have any suggestions? Thanks !

[LarryOsterman]

Changes look good to me, thanks for the contribution.

Btw, the breadth of compilers we deal with makes most PRs challenging, I'll take a quick peek to see if I can figure out what's going wrong.

ETA: I suspect that the problem may be that the Args template parameter pack may be interfering with the template definition for is_assignable.

    // Check if T is assignable from U
    template<typename U>
    static constexpr bool is_assignable = std::is_assignable<T&, U>::value;

I'm not 100% sure about this, but based on my experience MSVC tends to be a lot more permissive than other compilers.

[antkmsft]

Thank you @jnyfah for your contribution!
This looks pretty solid. I'd love to see our SDK types covered by these tests.
How many types are you planning to cover?
In its current state, when CI succeeds, it is pretty good already as an example to copy-paste and multiply for the rest of the types, so it is up to you where you want to make a break or a stop. But even if it goes in just for the ETag type, it is atomic and it would leave our repo in a consistent state, and definitely in a better state than it was before.
The only thing we'd need to fix now is the failure of these tests:

146 - azure-core.Etag.Assignable (Failed)
	147 - azure-core.Etag.Constructible (Failed)
	148 - azure-core.Etag.CopyAndMoveConstructible (Failed)
	149 - azure-core.Etag.CopyAndMoveAssignable (Failed)
	150 - azure-core.Etag.Destructible (Failed)

I haven't looked deeply, but it looks like there is a problem with the method that we currently use to detect Destructible, for example, because I don't think ETags are not destructible, so there seems some disconnect there.

[jnyfah]

Thanks @LarryOsterman, figured it out, it was static constexpr, the way clang handle the instantiation is different from that of MSVC.

[jnyfah]

@antkmsft, fixed the tests it looks like there's another person showing interest in working on this as well. I don't want to hog all the fun by myself 🙂, so I think it would be great if we could collaborate. I would love to start with the azure.core types.