Re: [boost] [core] Determining interest for two new classes: readonly and newtype

Subject: Re: [boost] [core] Determining interest for two new classes: readonly and newtype
From: Sam Kellett (samkellett_at_[hidden])
Date: 2015-08-17 18:31:16

> readonly<T>:
>>
>> [snip]
>
>
>
How is this relatedto this proposal
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4388.html
>

if i understand correctly that is about getting fields that are pointers to
respect the const-ness of the object they belong in. so,

struct foo {
  std::string *s;
};

const foo f;
f.s->clear() // even though f is const i can still call a non-const method
on one of it's members.

whereas readonly simply provides a guard against non-const methods on the
field itself (so, the pointer, not the pointee if you were to use it for
the above struct) without making the field actually const (so as to still
allow moving).

struct foo {
  readonly<std::string *> s;
};

const foo f;
f.s*->clear(); // will still work, it's only the pointer that is now
immutable.

nb: *-> may or may not be required here, writing this straight into the
email and am not 100% that that is correct..

> -----
>>
>> newtype<N, T>
>>
>> [snip]
>>
>
>
You could take a look at the proposal for Opaque types [1].
>

this is nice. definitely solves the same problem. do you have any idea on
the status of that paper? the link is 2013, but i know that doesn't mean
much.. is it c++17 expected or later (or ever, atm)?

> I would be grateful if you can tell me what do you think of a prototype I
> started longtime ago [2]. Please, note that it is not my intention to
> discourage you with your proposal, as the scope of your class much simpler.
>

this is nice too, i played around with the idea of allowing certain traits
of types to propagate through newtype (ala Haskell's deriving statement)
but opted on the simplicity side just for my use case. if i wanted a set of
newtype<struct foo, int>'s i would simply define a overload for > for that
typedef.

i didn't want to do it by default as it's presumptious to assume any type
that is represented by an integer would be orderable, but some sort of
solution that allows you to pass in a list of additions like you had could
form a proper general solution.

    using byte = newtype<struct byte_t, int, deriving<typeclass::show,
typeclass::eq, typeclass::ord>>;

    std::cout << byte{10} << std::endl; // show
    assert(byte{10} == byte{10}); // eq
    using byte_set = std::set<byte>; // ord

that could be quite nice and something i would be happy to look into as
part of the move towards boostifying these classes, should people think
they have a place here.