Are you trying to make client code unable to store a variable of foo::bar?
The intent being that you can foo::print_bar(foo::make_bar()); but not
/*variable*/ x = foo::make_bar();
foo::print_bar(x);
It's possible to (forward-)declare a type without fully specifying its layout. If you do that, like in the (P)rivate (Impl)ementation pattern, you prevent callers from another compilation unit from being able to create instances of your class.
However, if you do that, foo::make_bar() must return - and foo::print_bar() must accept - a pointer to foo::bar, not an actual foo::bar instance itself. And callers will still be able to store the result from make_bar() into a variable.
If that does not solve your situation, I would look into the various ways that class objects can be created, initialized, and mutated and start removing them from foo::bar until the problem is solved to your satisfaction. For instance, if foo::bar can't be assigned from another foo::bar, you'll prevent x = foo::make_bar(); but not for instance x{foo::make_bar()}; which is at least a good start.
This is a fun puzzle, but I'm wary of going deeper into a solution if this is going to be used in production code. I'd like to hear more about why this restriction is necessary before trying too hard to implement it, because I am wary of The XY Problem and want to solve the underlying problem, not the surface problem.
Are you trying to make client code unable to store a variable of foo::bar?
The intent being that you can
foo::print_bar(foo::make_bar());but notIt's possible to (forward-)declare a type without fully specifying its layout. If you do that, like in the (P)rivate (Impl)ementation pattern, you prevent callers from another compilation unit from being able to create instances of your class.
However, if you do that,
foo::make_bar()must return - andfoo::print_bar()must accept - a pointer to foo::bar, not an actual foo::bar instance itself. And callers will still be able to store the result from make_bar() into a variable.If that does not solve your situation, I would look into the various ways that class objects can be created, initialized, and mutated and start removing them from foo::bar until the problem is solved to your satisfaction. For instance, if foo::bar can't be assigned from another foo::bar, you'll prevent
x = foo::make_bar();but not for instancex{foo::make_bar()};which is at least a good start.This is a fun puzzle, but I'm wary of going deeper into a solution if this is going to be used in production code. I'd like to hear more about why this restriction is necessary before trying too hard to implement it, because I am wary of The XY Problem and want to solve the underlying problem, not the surface problem.
I haven't thought about problem in a concrete situation.
This entry is an episode that I found that what was possible in C++03 became impossible in C++11.