[API] Inconsistent usage for Property Map misuse produces different, unhelpful errors

[Becheler]

Not sure this is a very helpful issue, as I am still catching up on Boost Concepts, but I will drop it for the record and discussion

Problem 1: Algorithms that perform no check at all

When a user passes a property map with the wrong category to an algorithm, the compiler error is deeply nested and unhelpful.

For example, passing a read-only distance property map to dijkstra fails to compile with a long and rather cryptic error, ending with

app/boost/include/boost/property_map/property_map.hpp:311:40: error: lvalue required as left operand of assignment
  311 |     static_cast<const PropertyMap&>(pa)[k] = v;

See on Compiler Explorer

Problem 2: Algorithms that check boost concepts

Some algorithms like Bellman use Boost Concepts to check the property map category, but the output is actually worse than no check.
See on compiler explorer

Proposal

I guess the use of Boost Concepts is justified by pre-C++11 static_assert. Also for documentation purpose. But maybe we should open a conversation on making compilation error messages more clear.

Maybe add static_assert checks for property map categories in algorithms that currently lack them:

static_assert(
    std::is_convertible<
        typename property_traits<DistanceMap>::category,
        read_write_property_map_tag>::value,
    "distance_map must be a ReadWrite property map (supports both get and put)");

This produces a single line error:

error: static_assert failed "distance_map must be a ReadWrite property map 
(supports both get and put)"

See on Compiler Explorer

[andreacassioli]

Improving the quality of the error messages at compile time would be a good step to improve the developer experience!

Besides, moving from Boost concepts to std concepts could also help lowering the (very) high bar to contributors, as one would not need to know the Boost concept library but rather the standard concepts.

[Becheler]

Yes I agree ! The bar is so high 🥲

I think we should plan for a way to transition out of Boost concepts at some point, but that would mean dropping support for C++ < 20 and we don't know yet if most users want that in the short term. I believe @jeremy-murphy is working on one of his magical surveys to understand if users prefer stability/inertia or moving fast and breaking stuff. And we will have the workshop feedback #466

I would rather spend some time making the documentation better, fixing gaps and bugs and solve users' immediate needs that don't require such a bump. After all most examples are still written in C++03 I believe, many don't even compile and many features still need to have an example ahaha

I am working on drafting a "How To Submit an Algorithm" page or something. My hope is that it would make it easier for contributors to have a squeleton algorithm to populate, with a good step by step process. Rather than having to guess the steps from existing algorithms 😄

Then once lib is on its two feet again, with better doc/algo/test coverage and a lesser backlog of issues, that may make it more comfortable to envision a bump to very-modern-c++. But that would be a fairly hard task,

What do you think @andreacassioli ?