P4167R0: reflection annotations to control ADL

Fixing the example

So how we would fix the example? Type of awesomeness already has the custom namespace associated with itself. But problem is the quantity template and more precisely derived_unit template which is result of awesomeness / sec expression. We can modify the quantity first:

template<Reference auto R, RepresentationOf<get_quantity_spec(R)> Rep = double>
class quantity [[=associated_entities(get_associated_entities_of(^^R))]] {
	// ...
}

For a moment let's pretend we have std::meta::get_associated_entities_of and std::meta::associated_entities functions, they are found itself by ADL. First function get_associated_entities_of provides all associated namespaces / classes for purposes of ADL of type of R, and associated_entities provides annotation to quantity template instance.

Same modification will be needed in derived_unit, scaled_unit, ... and everywhere else where such transitive propagation is required for good user experience.

template<Reference auto R, RepresentationOf<get_quantity_spec(R)> Rep = double>
class quantity [[=expand_associated_entities_from(^^R))]] {
	// ...
}

Shape of additional_associated_entities

Special library type additional_associated_entities is designed to be stored in annotation. When compiler starts ADL, it can look at the annotation and if the object is there it can access to get additional entities. One possible approach could be:

struct additional_associated_entities {
	span<const meta::info> _data;
	consteval auto begin() const noexcept { 
		return _data.begin();
	}
	consteval auto end() const noexcept { 
		return _data.end();
	}
};

Compiler will then iterate the range of meta::info and adds each reflected entity into the associated entity list.

Opt-out of ADL

With similar approach we can provide opt-out of specific or all associated entities by providing two more types:

struct disassociated_entities {
	span<const meta::info> _data;
	consteval auto begin() const noexcept { 
		return _data.begin();
	}
	consteval auto end() const noexcept { 
		return _data.end();
	}
};

struct disabled_all_associated_entities {
	// just nothing
};

If annotations are remember in same order as declared, associating with only specific entities can be done via specifying these annotations in specific order. Alternatively more complex annotation type can be provided.

struct custom_associated_entities {
	bool disassociate_everything;
	span<const meta::info> disassociated;
	span<const meta::info> associated;
};

Or alternatively provide override mechanism:

struct associated_entities_override {
	span<const meta::info> _data;
	consteval auto begin() const noexcept { 
		return _data.begin();
	}
	consteval auto end() const noexcept { 
		return _data.end();
	}
};

ADL as a library code

Of course providing span of meta::info is cumbersome, so a helper functions are needed:

consteval auto gather_associated_entities_of(meta::info entity) -> std::set<std::meta::info> {
	if (!is_value(entity)) entity = type_of(entity);
	if (!is_type(entity) && !is_namespace(entity)) {
		throw meta::exception("entity is not value, type, nor namespace", entity);
	}
	
	if (!has_parent(entity)) {
		return {};
	}
	
	// I know we don't have ordering or hashing here, but let's pretend we have
	std::set<meta::info> result{parent_of(entity)};
	
	// all parent's entities are associated
	result.insert_range(gather_associated_entities_of(parent_of(entity)));
	
	// process bases
	if (is_class_type(entity)) {
		for (meta::info bases: bases_of(entity)) {
			result.insert_range(gather_associated_entities_of(bases));
		}
	}
	
	if (has_template_arguments(entity)) {
		for (meta::info ta: template_arguments_of(entity)) {
			if (is_type(ta)) { // normal ADL ignores values, so we will too
				// TODO: make sure this is not infinite loop
				result.insert_range(gather_associated_entities_of(ta));
			}
		}
	}
	
	// process annotations
	// I process all types of override (just to show how straight-forward it is)
	for (meta::info annttns: annotations_of(entity)) {
		if (typeof(annttns) == ^^disabled_all_associated_entities) {
			result = {};
		} elseif (typeof(annttns) == ^^disassociated_entities) {
			for (meta::into negative: extract<disassociated_entities>(annttns)) {
				result.erase(negative);
			}
		} elseif (typeof(annttns) == ^^additional_associated_entities) {
			result.insert_range(extract<additional_associated_entities>(annttns));
		} else if (typeof(annttns) == ^^associated_entities_override) {
			// replace here
			result = extract<additional_associated_entities>(annttns) | std::ranges::to<std::set>
		}
	}
	
	return result;
}

consteval auto override_associated_entities(std::set<meta::info> entity) {
	// obvious straightforward thing
	return associated_entities_override{define_static_array(entity)};
}

Extending set of associated entities

This is currently not worded, as I worded replacement. Will need addition of an annotation type additional_associated_entities which will contain a span of reflection for these entities. There is no need to provide a function to gether them, only a convininent constructor:

namespace std::meta {
	struct additional_associated_entities {
		// ...
		consteval additional_associated_entities(std::initializer_list<std::meta::info>) { ... }
	}
}

// usage
struct my_type [[=additional_associated_entities(^^custom)]] { ... }

Replacing associated entities set

This is what I worded, it's the most powerful option. But it puts a responsibility on library to be in sync with language algorithm to gather associated entities.

Addition / Removal / Disable of all associated entities

Library will need to provide multiple annotations or a DSL to express this. It will make the language wording in [basic.lookup.argdep] much more complex.

Language wording

Library wording

Will provide wording for function override_associated_entities, gather_associated_entities_of, and other functions.

Feature test macro

__cpp_adl_override 202???