Date: Fri, 21 Feb 2020 12:48:36 +0000
Peter, your library is great. The structure is extremely useful - being
able to generalise operations through absolute and relative types is really
nice (e.g. Being able to define a time and a timedelta, such that you can
add a timedelta to a time, and subtract two times to get a timedelta, but
not being able to add two times).
Matt, if this were to become a language thing, I don't see how the above
could be done so easily. I also wonder how it would handle a function
declaration that occurs /after/ the "using new" statement. If A and B are
both using new X, and a function f(X, X) is declared after the definitions
of A and B, is f(A, A) valid? f(A, B)?
On Fri, 21 Feb 2020, 12:16 Matt Hurd via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> see my "PSSST" (Peter's simple strong typing) framework attempt (not
>> finished) at
>>
>>
>> https://github.com/PeterSommerlad/Psst/blob/master/cevelop-workspace/PssstTest/src/pssst.h
>>
>> achievable through a library, so no need to change. In addition it allows
>> you to clearly limit the available operations to a set suitable for your
>> domain specific type. For usage see accompanying test cases.
>>
> Thanks Peter. That's a nice approach.
>
> PSSST has similar goals to another couple of libs I've used for safety and
> strong typing of numerics. However, I'm thinking about a more fundamental
> thing of cloning a type without it being seen as the same type by the
> compiler's type system.
>
> I'm also wondering if such a thing may be useful for also extending
> things, such as tuples, optional, vector, variant without the potential
> pitfalls of inheritance. Though different composability customisation
> points would be useful in such situations (pre, post, invariant, in, out,
> dot operator, etc). C# has extension methods and we have difficulties
> without the promising C++3a reflection/rewriting. Unfortunately C++ may
> fail to optimise properly across abi boundaries for simple composed types
> which can be frustrating (the infamous unique_ptr example). Performance
> concerns makes my own simple wrapper types feel a queasy as I'd like to get
> out of the optimiser's way as much as possible.
>
> Kind regards,
>
> --Matt.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
able to generalise operations through absolute and relative types is really
nice (e.g. Being able to define a time and a timedelta, such that you can
add a timedelta to a time, and subtract two times to get a timedelta, but
not being able to add two times).
Matt, if this were to become a language thing, I don't see how the above
could be done so easily. I also wonder how it would handle a function
declaration that occurs /after/ the "using new" statement. If A and B are
both using new X, and a function f(X, X) is declared after the definitions
of A and B, is f(A, A) valid? f(A, B)?
On Fri, 21 Feb 2020, 12:16 Matt Hurd via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> see my "PSSST" (Peter's simple strong typing) framework attempt (not
>> finished) at
>>
>>
>> https://github.com/PeterSommerlad/Psst/blob/master/cevelop-workspace/PssstTest/src/pssst.h
>>
>> achievable through a library, so no need to change. In addition it allows
>> you to clearly limit the available operations to a set suitable for your
>> domain specific type. For usage see accompanying test cases.
>>
> Thanks Peter. That's a nice approach.
>
> PSSST has similar goals to another couple of libs I've used for safety and
> strong typing of numerics. However, I'm thinking about a more fundamental
> thing of cloning a type without it being seen as the same type by the
> compiler's type system.
>
> I'm also wondering if such a thing may be useful for also extending
> things, such as tuples, optional, vector, variant without the potential
> pitfalls of inheritance. Though different composability customisation
> points would be useful in such situations (pre, post, invariant, in, out,
> dot operator, etc). C# has extension methods and we have difficulties
> without the promising C++3a reflection/rewriting. Unfortunately C++ may
> fail to optimise properly across abi boundaries for simple composed types
> which can be frustrating (the infamous unique_ptr example). Performance
> concerns makes my own simple wrapper types feel a queasy as I'd like to get
> out of the optimiser's way as much as possible.
>
> Kind regards,
>
> --Matt.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-02-21 06:51:23