While returning something that decomposes to a locked mutex is indeed of questionable direct use from my perspective as well, I think we're missing the obvious (unless any fellow dev already stated):

struct getLockedMutex {

    std::mutex m;

    getLockedMutex() { m.lock(); }

};

Now, if we can set aside mutex for a while... Indeed, both 'returning char[]' and 'non-movable object' came up this week at work, plus I'm regularly working with handcrafted reflection. While this is not what I'm here for, an object-oriented alloca() - or, if you prefer, annotations - could hit these 3 birds with a stone. What I mean: expr1 @ expr2 could be assigned the following meaning:

- type of expr1 @ expr2 is same as type of expr1

- throwing expr1 @ expr2 is the same as throwing expr1 (expr2 is not evaluated)

- type of @(expr1 @ expr2) is same as expr2 and is allocated (in case of ASDV):

    - when directly returning it, i.e., return expr1 @ expr2, in the caller's scope, amongst ASDVs

        - returning expr1 @ expr2 requires either the function or lambda specification to contain the annotation (in some form not yet decided at the time of writing)

        - evaluation of expr2 in this case is scheduled-before destruction of automatic storage duration variables in the function's scope (thus those variables and function arguments are still available), but scheduled-after evaluation of expr1

    - when accessing a member variable, in the scope where the access takes place, amongst ASDVs

    - in any other context, in the current scope (but I'm okay with caller's scope as well)

- when expr1 @ expr2, or a function that returns annotated, is directly used as initializer in a definition of an ASDV, member variable, global variable or function-local static variable a_var, (i.e., auto x = expr1 @ expr2; or struct S { int i = 1 @ "name-of-i-in-serialization"; }; ), both the defined variable and the annotation are introduced, in this order.

    - evaluation takes place each time when the annotation @a_var is accessed

- for expr1 @ expr2, in expr2, @@ is a reference to expr1 (the evaluation of expr1 is sequenced-before the evaluation of expr2, so this is doable). This allows for calling functions on the non-movable object being returned.

Note that the two names mean that a function call f(expr1 @ expr2) is still the same as f(expr1), but a function returning annotated is to allocate in caller's scope (hence the analogy to alloca) and, for member variables, it's always evaluated when accessed. Thus, it brings us the infamous post-constructor for returning non-movable object, some semi-manual reflection/introspection for serialization-deserialization, the ever-returning 'how to return char[]'; for some realistic use-cases, it'd permit non-movable types with private ctor and named try-constructor (static member function that returns std::optional<T> or std::expected<T, E> because it might or might not fail for the arguments).

Obviously, @ and @@ are simply placeholders for any better syntax. Anyways, this might work for the use-cases on this thread, but I'm rather off to my old proposal, statement expressions, as that could bring some real value to HFT I think...

Bests,

-lorro