erichkeane wrote: > I could see that it would be useful to have an attribute > `[[clang::container(T, additional-properties)]]`. The type this is applied to > would be guaranteed to fulfill [container.requirements] as well as whatever > other properties `additional-properties` require. Initial ideas for > `additional-properties`: > > * "sequence-container" for [sequence.reqmts] > > * "node-container" for [container.node] > > * "associative-container" for [associative.reqmts] > > * "reversible-container" for [container.rev.reqmts] > > * "allocator-aware-container"(Alloc) for [container.alloc.reqmts] > > * "enforce-allocator-requirements" to diagnose incorrect allocators > > * "enforce-completeness-requirements" for the initial goal of this patch > > > We of course wouldn't want to allow nonsensical combinations like > "sequence-container" and "associative-container" or > "enforece-allocator-requirements" without "allocator-aware-container". > > I'm not quite sure whether "allocator-aware-container" should be done in that > way, but that seems like a rather niche detail. > > WDYT? Is that a direction worth pursuing?
The first 5 are exactly the kind of thing I was getting at... something written in source that guarantees to the compiler that, even though we can't do the analysis, the author of it promises is the case. The last 2 (and I realize are the important ones to you) are a different beast, in that they aren't guarantees to the compilers, but requests for the compiler to 'check'. I'm still very sympathetic to the intent of the original patch here, I can see the attraction of an `enable-if-but-with-non-SFINAE-error` type requirement on a function template for the purposes of better diags. I just don't know what ergonomics are right for it yet. https://github.com/llvm/llvm-project/pull/211231 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
