P0900: Per Property Assignability combined with "default property mode"

[crtrott]

In order to get through the "pass it into a generic context" and everybody can convert into everybody quandary we could propose that every property has a default mode. If a span with a property A and a mode alpha is trying to get to assigned to a span which doesn't have property A than assignability is determined by the compatibility of mode alpha with the default mode of A. Thus for example the default mode of atomic_access could be false and the property could define that assigning atomic_access with true to a span with false is not allowed. Thus we have a pretty straight forward non-exponential mechanism to distinguish between properties where it is safe to just ignore the property then passing a span to a function and properties, such as atomic, where it may not be safe to do so. The beauty of this approach is that each property itself is responsibility to define the validity of a decay. One requirement of the default mode of a property would be that it does not have any effect on the span, i.e. it is the same as not defining it.

[hcedwar]

Can you get a wording update pushed in the next couple of hours?

[dhollman]

I don't see how this does anything to solve the problem with deduced contexts. The problem is with deduced template parameters, which will be deduced to whatever they are in the calling context regardless of the default.

[dhollman]

Also, the intent is definitely that properties do have a default mode. But to me this seems to be only applicable to non-generic contexts. How would this be applied to deduced template parameters?

[crtrott]

I thought that for deduced template parameters all properties will simply be forwarded. In cases where a specific property needs to be excluded you simply don't do a generic one, and set the properties you expect yourself. Using some kind of is_assignable<mdspan<T[][],layout,PropertiesA>,mdspan<T[][],layout,PropertiesB> thing would allow you to have different function implementations based on whether your can accept the generic ones or not. Generally we have been trying to set properties pretty local i.e. at the kernel or even function level.

[dhollman]

That's one of the options I put in the paper. (and you don't need is_assignable; convertibility suffices). The problem is that because of the way template argument deduction works you can't mix deduced properties in with non-deduced ones. Without some other mechanism, you either have to go all or nothing. That means any, e.g., library provided generic functions either can't be used with vendor-defined properties or those properties will be automatically (perhaps dangerously) deduced.

[dhollman]

The other problem with setting properties you can expect yourself is that the properties customization point would then not function for vendor or user customization (at least not when interacting with anything in the standard library). There has to be a way to ask the property itself. Think about bounds checking. The default should clearly be false, but if you want to pass something through to a generic context that you may have incorrectly configured, you're going to want bounds checking to stay on. I don't see how default values helps with this sort of problem, though I might be missing something.

[crtrott]

Yeah ok I see what you mean now. I have been reading this a couple times now and understanding comes in steps ;-). I believe that the "change the property value for generic capture" approach is weird. Basically I would expect that if I template on a span the type I get inside my generic function should be the same type as in the call place. Is there any example in C++ where this is not the case?

But let me first ask is your intent that this could print "False":

template<class ... Properties>
struct A {
   typedef span<double[],Poperties...> spanA;
   template<class spanB>
   struct B {
      enum {is_same = std::is_same<spanA,spanB>::value};
   };
   void eval() {
      if(B<spanA>::is_same)
        printf("True\n");
      else 
        printf("False\n");
   }
};

I.e. did I understand that section pretty close to the end right. 

[dhollman]

Yeah, that should print "True" always (I don't actually see how it wouldn't as a library feature). Also those properties aren't deduced, so it wouldn't be a problem. But I agree, I don't like the idea that someone would get unexpected behavior at a call site.

I don't actually like any of the solutions to the "generic propagation" problem, which is why I presented three possibilities to see what people think. I don't like the "all" approach (for reasons like restrict) and I don't like the "nothing" approach (for reasons like bounds_checking and atomic). I was basically trying to propose a third option, which I don't really like either because there isn't really precedent for it in the standard, but at least it addresses all of the cases we know about.

[crtrott]

But doesn't everything except the "all" approach make a "False" answer possible? Maybe we could just say something like that the other to possibilities are just thought experiments for completeness, but that we explicitly believe that the "all" approach is the only one in accordance with current C++ practice?

[crtrott]

Can we discuss for a couple of minutes on the Slack Kokkos channel which is now revived ?

[dhollman]

Sure, what's the URL?

[crtrott]

https://kokkosteam.slack.com

[crtrott]

Ok my issues are basically resolved between more reading and some short discussions. For the record David and I independently came up with the same answers to the straw poll questions:

• Extent/Layout is not part of properties
• yes (with order dependency for simplicity)
• no
• don't know what the preference of the community is nowadays, but lets go with the "common modern" approach
• guidance to generally not propagate properties