RFC: Support for Block Pointers as Non-Type Template Parameters

Clang Frontend
1

Hi everyone,

I’ve been working on a patch to allow Block Pointers (the ^ extension) to be used as Non-Type Template Parameters (NTTPs). Right now, i think this is a significant gap in our template support where function pointers and even lambdas (since C++20) work perfectly as NTTPs, but our own block extension is left out. I’ve been implementing the necessary Sema and mangling support so we can finally have feature parity for blocks in generic programming.

i think it is really important that we get this addressed because developers working in Objective-C++ or Clang-heavy environments rely on blocks for closures and asynch callbacks. If we can’t use them in templates, they remain isolated from the type system, which makes building generic wrappers. We want the blocks extension to feel like a first-class part of the Clang ecosystem, especially when it comes to modern C++ patterns.

The reason I’m writing this RFC is that while the basic implementation is coming along, I’ve run into some important questions regarding linkage and ABI. Specifically, to support blocks as NTTPs, we need to give the underlying block objects a stable identity across translation units. I know this is a sensitive area for the ABI ( @rjmccall has already shared some initial thoughts ), so I am looking for anyone with experience in SemaTemplate, Mangle, or ABI/Linkage to help me forward so we can get this landed correctly.

I’m really excited to help make blocks more powerful within Clang. If anyone has time to take a look at the proposed approach or point me toward the right reviewers for the ABI/Sema side.

I would be happy if this work would be reviewed and guided forward. Thanks all, and feel free to review the proposal and here is the patch

cc @shafik @erichkeane @mizvekov

2

I think the hesitation is not just that this is a big extension but also we want to see that there is a need and not just a want to have this features.

Are there several large scale Objective-C++ projects that are being blocked or forced to use unwieldy alternatives because of the lack of this feature in some way? Some alternatives were suggested but there was no discussion about why those alternatives were not usable as opposed to just being preferred.

We don’t want to long-term maintenance burden unless there is a real need.

1 Like