Re: Limited initialization for non-limited types

[Eric Hughes <eric.eh9@gmail.com>]

On Mar 28, 12:56 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Moreover, I was one of those that was not originally convinced that a
> function makes an adequate constructor. But I wasn't able to convince
> others, and eventually you have to compromise and move on.

I haven't been able to find a smoking-gun example that you can't work
around with existing syntax.  I'm keeping my eye out for one, though.
The best I know of now is that it's problematic to eliminate default-
value initialization at compile-time (easy to do at run-time).  This
is useful only for types where no default value is sensible (such as
not-null-access types) and it's only relevant within a private
implementation (by eliminating public visibility of components).  On
the other hand, it's a missing aid to an implementer--in the same
class of aid as "type Index is new Integer"--not strictly necessary,
but a felicity of the language.

As to the technical part of the idea, I'll propose "::=" as token for
the initialization operator.

As to the build-in-place requirement, it seems part of a larger idea
I've been mulling over, which is a more general representation
facility.  As an example, in an ideal world, I'd like to have the
Convention, Import, and Export pragmas become ordinary code.  The core
theory is in Tony Hoare's paper "Proof of Correctness of Data
Representations" (1972).  Its essence is a formal way of mapping
between two different representations with equivalent ultimate
effect.  The largest visible change to Ada (or to any other language)
would be to make identifiers both for representation languages (name
spaces) and for representation conventions (maps between them).  I
doubt this will happen any time soon, though, since it seems a solid
research project to develop the necessary pragmatic theory to apply
this to a real language.

> Code that requires a
> particular sequence of calls is wrong (even though it might work).

Well, I'm not looking for any particular sequence of calls, really.
My immediate application is to verify invariants in run-time by
trapping on particular events (right now it's those of Controlled).

> I still think that your entire approach is wrong. I'd probably either try
> something using a mixin generic, or more likely simply with a bit debugging
> code built into the base class.

I looked at initialization first because it's more widely applicable
outside of my immediate need, for which I think type discriminants may
work.  A discriminant whose access_definition is a handle to ordinary
record seems to allow most everything I can think I need soon.


[re: private components]
> It would take quite a bit of thought to ensure that such
> problems don't lurk here.

Granted.

Eric