@@ -1703,7 +1703,7 @@ that type and cast it to `void`, for the same reason as we did for non-static
1703
1703
members.
1704
1704
1705
1705
1706
- @subsubsection tutorial-introspection-is_valid-typename Nested type names
1706
+ @subsubsection tutorial-introspection-is_valid-nested- typename Nested type names
1707
1707
1708
1708
Checking for a nested type name is not hard, but it is slightly more
1709
1709
convoluted than the previous cases:
@@ -1716,7 +1716,7 @@ support types that can't be returned from functions, like array types or
1716
1716
incomplete types.
1717
1717
1718
1718
1719
- @subsubsection tutorial-introspection-is_valid-template Nested templates
1719
+ @subsubsection tutorial-introspection-is_valid-nested- template Nested templates
1720
1720
1721
1721
Checking for a nested template name is similar to checking for a nested type
1722
1722
name, except we use the `template_<...>` variable template instead of
@@ -1725,6 +1725,21 @@ name, except we use the `template_<...>` variable template instead of
1725
1725
@snippet example/tutorial/introspection.cpp nested_template
1726
1726
1727
1727
1728
+ @subsubsection tutorial-introspection-is_valid-template Template specializations
1729
+
1730
+ Checking whether a template specialization is valid can be done too, but we
1731
+ now pass a `template_<...>` to `is_valid` instead of a `type<...>`, because
1732
+ that's what we want to make the check on:
1733
+
1734
+ @snippet example/tutorial/introspection.cpp template_specialization
1735
+
1736
+ @note
1737
+ Doing this will not cause the template to be instantiated. Hence, it will only
1738
+ check whether the given template can be mentioned with the provided template
1739
+ arguments, not whether the instantiation of the template with those arguments
1740
+ is valid. Generally speaking, there is no way to check that programmatically.
1741
+
1742
+
1728
1743
@subsection tutorial-introspection-sfinae Taking control of SFINAE
1729
1744
1730
1745
Doing something only if an expression is well-formed is a very common pattern
@@ -2024,7 +2039,10 @@ a container unspecified; they are explained in the
2024
2039
[rationales](@ref tutorial-rationales-container_representation).
2025
2040
When the representation of a container is implementation-defined, one must
2026
2041
be careful not to make any assumptions about it, unless those assumption
2027
- are explicitly allowed in the documentation of the container.
2042
+ are explicitly allowed in the documentation of the container. For example,
2043
+ assuming that one can safely inherit from a container or that the elements
2044
+ in the container are stored in the same order as specified in its template
2045
+ argument list is generally not safe.
2028
2046
2029
2047
2030
2048
@subsubsection tutorial-containers-types-overloading Overloading on container types
@@ -2817,9 +2835,12 @@ very useful for porting existing code from e.g. Fusion/MPL to Hana:
2817
2835
@snippet example/tutorial/ext/fusion_to_hana.cpp main
2818
2836
2819
2837
@note
2820
- At this time, only adapters to use data types from other libraries inside Hana
2821
- are provided; adapters for the other way around (using Hana containers inside
2822
- other libraries) are not provided.
2838
+ - At this time, only adapters to use data types from other libraries inside Hana
2839
+ are provided; adapters for the other way around (using Hana containers inside
2840
+ other libraries) are not provided.
2841
+
2842
+ - The Fusion and MPL adapters are only guaranteed to work on the version of
2843
+ Boost matching the version of Hana being used.
2823
2844
2824
2845
However, using external adapters has a couple of pitfalls. For example, after
2825
2846
a while using Hana, you might become used to comparing Hana tuples using the
0 commit comments