Hi All, "Restrictions" (lazy arrays) in Boost.Multi look like a useful and practical component. The below feedback may sound negative, but it should be treated as suggestions for improving the feature. I find the name "restriction" surprising. Is this a term of art? "Lazy array" immediately conveys the idea, so I wonder why you decided to go with "restriction". I already complained that the "Reference" section is not serving its purpose well. Regarding "restrictions", they are simply missing from that section. Having read the tutorial, and wanting to use the feature in my program, I need to know: 1. Which header to include 2. What is the type returned by the "wedge" operator 3. Is the return type something that I should be able to name, use? Or is the contract "just assign the result to your array, and don't ask for the type name"? 4. What are the preconditions of the operation? 5. Are there things that I can do wrong when using the function and resulting types? 7. Does the function that I provide need to have the same number of arguments as the number of dimensions in the `extents` that I provide? 8.Do you guarantee that the index values that will be passed to subsequent invocations of my function will come in specific order? Or do I need to make sure that my function is pure/regular? 9. Does the function that I provide need to be copyable? 10. Header `restriction.hpp` has functions `make_restriction()` defined. Are they intended for users? If so, they need to be listed in "Reference"' also. I question the choice of using an arbitrary operator for creating lazy arrays. It makes the user code difficult to read and understand. I imagine that in my company I assign a junior developer to fix something in the code, and they are exposed to these bitwise-xor operators. This is an unnecessary confusion. A named factory function like `make_lazy` would immediately sell the intent: it combines the extents with an "indexes-to-value" function to produce a lazy array. It looks like there is an implied concept in your library, "non-mutable array access"., which probably includes being the RHS of the assignment to a "mutable array access". Now I feel even stronger that it should be given a name and be defined, even if semi-formally. The tutorial for restrictions mentions the function ".home()". Is this intended to be part of the library's interface? If so, it must appear in the "Reference" section. The Reference section defines what is the intended interface of the library as opposed to declarations that happen to exist in the headers for other reasons: as temporary solutions, implementation details, experiments or artifacts. Regards, &rzej;