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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-08-18 02:57:36

Le 18/08/15 00:31, Sam Kellett a écrit :
>> 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..
How both wrappers could work together?
>
>> -----
>>> 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)?
See Joel response. I suspect that the last question depends on the work 
the author is able to do.

Any comments about implicit/explicit conversion from/to the opaque type 
and the underlying type?
Does your class support some of them?
>
>> 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.
>

Note that you could also add them conditionally (SFINAE).
Count with my help if you decide to go on.

Best,
Vicente