Re: two questions on allocators

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 01/03/2018 00:37, Randy Brukardt wrote:
> "Robert A Duff" <bobduff@TheWorld.com> wrote in message
> news:wcczi3t6qqh.fsf@TheWorld.com...
>> Mehdi Saada <00120260a@gmail.com> writes:
>>
>>> I saw that since I (tried to) read the AARM, but didn't really got
>>> it. Now it's ok. If the problem of these null forbidding hypothetic
>>> subtypes is that can't have the default null value, why not just require
>>> the user to give one ?
>>
>> Don't use "not null"; it's broken as you see.  Instead, do:
>>
>>     subtype S is T with Predicate => S /= null;
> 
> ??? You'd get the same problem with the allocators (that they always raise
> an exception) with this formulation.
> 
> If you did want a subtype to use for an initialized allocator (which the OP
> specifically wasn't using), then
> 
>      subtype S is not null T;
> 
> works just fine. And this at least is guaranteed to be checked everywhere
> necessary, that's not true for a Dynamic_Predicate (as you know).
> 
> Probably in most cases, they are equivalent, but when they are not
> equivalent, it is just because you have pushed static checks to runtime,
> which hardly seems to be an advantage.

True. Dynamic checks is evil unless a contract. The contract "raise 
Constraint_Error if null" is already there, which makes all exercise 
pointless.

---
As I keep on repeating: constructors, they must be here. There is no way 
to work that fundamental block around. Otherwise we will always be 
running into the same problem that any assignment has a left side, which 
must be come from somewhere and be conform with all constraints 
including ones of the right side.

There is nothing wrong with "not null access" except for lack of 
constructors in Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de