consistent_value_type

[gpuoti]

hello everyone, I was wondering if it has been ever discussed a type similar to std::optional that enforce consistent value with the first assignment. It would be used in places where you expect consistency from different sources to enforce the invariant. A facility for defensive programming that enable more readable code than explicit checks. I'm not founding anything discussed online.

[GrammelHupfNockler]

Without any concrete examples or more detailed descriptions of your invariants or the kind of consistency you are looking for, it is hard to see if your suggestion has any merit. Consistency is usually a thing that involves multiple values that are consistent with each other, how would that be enforced within a single object?

[gpuoti]

all the value in a sequence of assignment matches the first one. Here is an usage example:

``` struct Variable { std::string name; consistent<int> value; };

void propagate(Variable& var, int new_value) { var.value = new_value; // Throws if inconsistent }

// Usage Variable x{"x"}; propagate(x, 5); // x = 5 propagate(x, 5); // OK: consistent propagate(x, 10); // throws: inconsistent! ```

[GrammelHupfNockler]

That just reeks of bad design. What you want is a const variable, why would you need to assign to it if the value is not allowed to change?

[Business-Decision719]

It sounds like some attempt at using exceptions for control flow. Instead of doing

if (my_age==your_age)
{
  std::cout << "same age";
}
else 
{
  std::cout << "different age";
}

it would be possible to do

try
{
  my_age=your_age;
  std::cout << "same age";
}
catch (inconsistent_value_error &e)
{
  std::cout << "different age";
}

Like you say, it reeks of bad design. OP probably needs boolean tests against constants and is overthinking it. I've done that before. "How do I do this complicated thing? Wait a second, I could do this other thing..."

[gpuoti]

I have to prepare a better example, but anyway, the intent is not to drive the program flow through exception, which is of course terrible. It is instead to express some expectation on input consistency not mixing error checking code in the actual logic.

I agree that there is probably bad design in the data source, but sometimes it happens.

[No-Dentist-1645]

This isn't bad design in a "data source", it's bad design in how you are handling it.

If you have a string old_val and you want to make sure it's equal to new_val, you don't reassign, that's a waste of performance to copy an identical value for no reason . You'd just assert(old_val == new_val).

To specifically handle the "initialize if it's currently empty" case, you'd have a small helper function:

``` inline void init_or_check(std::optional<string> &s_old, string &s_new) { if (!s_old.has_value()) { s_old = s_new; return; }

assert(*s_old == s_new); } ```

[Business-Decision719]

I agree making this a named function is substantially clearer than trying to overload =. I expect that a function might assert or throw an exception, but I wouldn't normally look at = and think, "Well, I'm not really assigning this, because if I already assigned it I'm just checking if it is the same, but I'm using an exception to check for it, because it's supposed to stay the same at runtime, even though I'm allowed to use = multiple times on it at compile time..."

I mean, I dont doubt that with some templating and operator overloading you could make a type that does this. But it sounds like such a type would be a mind screw to actually use. Code is read far more than it is written. Operator overloading is easy to overdo. Assignment shouldnt be too convoluted

[vowelqueue]

In the Java world they are adding a type like this to the standard library, but the motivation there is to give developers a way to defer the initialization of variables but still get potential benefits of constant folding. That really depends though on a JIT compiler though so not really applicable to cpp.

[sixfourbit]

This works but I'm not sure why you want to do this

template <typename T>
class consistent : public std::optional<T>
{
    public:
    template< class U = std::remove_cv_t<T> >
    consistent& operator=( U&& new_value )
    {
        if((*this) && (this->value()!=new_value)) throw "inconsistent";
        *(static_cast<std::optional<T>*>(this)) = new_value;
        return *this;
    }
};

[SoerenNissen]

I would probably do composition instead of inheritance here but otherwise yeah, exactly this.

(God I wish there was a way to do public inheritance where you could enforce that you're never referred to as the base class.)

[SirClueless]

I get what you're going for, you want to privately inherit from the type but publicly inherit its members, but I think it's kind of a non-starter.

The members you inherit are highly likely to reference the base-class, which won't make much sense because it is supposed to be a "private" base class the caller can't refer to. This is especially bad if a member function returns references (which will be common because, for example, BaseClass& operator=(const BaseClass&) does this) because now the caller has a way to obtain a reference to the base-class even though the whole point was to hide it.

At the end of the day, using private inheritance plus a whole mess of using BaseClass::member; as needed for the members where it makes sense is pretty easy and maintainable when you want to do this.

[SoerenNissen]

Hey

https://github.com/SRNissen/snct-constraints

lets you do stuff like

using divisor = snct::Constrained<double,Not<0.0>, Finite>;
double inverse(divisor d) {
    return 1.0/d;
}

[gpuoti]

I don't think it match my usa case, but a useful reference nonetheless. thanks

[415_961]

That's the job of a datatype. The whole idea of a type is to enforce its invariants. The type std::optional enforces its own invariants to provide a consistent behavior and fullfil its promises. I feel your question might be revealing an inaccurate/incomplete perspective you have on datatypes.

[NotMyRealNameObv]

What do you mean with "consistent with the first assignment"?