Re: Limited initialization for non-limited types

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

On Mar 26, 4:13 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> There's no way to require it. And I wouldn't expect that to change -
> *requiring* implementations to be able to call a single function with
> different return mechanisms seems way over the top.

The real goal I'm looking for is to suppress the extra calls to
Initialize/Adjust/Finalize.  The main obstacle is that the call to
Initialize which has the "right" initial values is in the function
body and the call to Initialize which has the ultimate 'Access value
is in the declaration.  For limited types, I presume this implies that
the 'Access value is passed implicitly to the function.  Hence for
this to work at all there would have to be restrictions on the
function used for initialization.  The exact restrictions are beside
the main point here, only that there is some restriction, which, then,
would require some kind of declaration on an acceptable function.  (I
didn't realize this when I first posted.)

So this critique is well taken.  It seems that a necessary component
of a solution is to require a certain kind of return mechanism.

> There is a second reason: implementations are allowed to optimize
> non-limited controlled types in almost any way that is "correct" (that is,
> an initialized object gets finalized).

OK.  So there's a specification about how initialization works
correctly.  I had assumed (silently) that this specification would be
expanded to have correct results both for assignment (including
initial assignment) and for initialization, and that they would not be
identical.  So this implies an enlarged specification.  I would assume
that the same optimization principle would apply to this new piece of
specification.

There's a syntactic ambiguity between ":=" for initial assignment and
":=" for initialization.  In retrospect, I find it unfortunate the
same symbol was used.  New syntax would be required to distinguish
these for non-limited types.

> I'd probably suggest finding a different approach. (Not that I can think of
> one off-hand.)

Well, I have an approach that will work, but it's pretty ugly.  I
posted in the hope that something would eventually be cleaner.

Reviewing:
1) Declaration of a function suitable for non-assignment
initialization.
2) New specification of controlled behavior with such initialization.
3) Syntactic distinction between assignment and initialization.

I wasn't looking for this when I started this thread, but isn't this
exactly what's needed to define a proper constructor function?


> > 2) Variable-specific record components. [...]
>
> Interesting, but sounds messy to implement, because it would complicate the
> "bit-copy" part of the assignment. That's not usually done
> component-by-component!

I see three consequence with this idea.  First, there's an existing
assumption that the copy-length is the same as the allocation-length.
I presume that all existing compilers conflate these (since there's no
existing reason not to).  The other assumption in this area is that
the offset of the modifiable portion is zero.  I see no reason to keep
this as a default, but it's not necessarily so in general.  My first
pass recommendation is that the default layout in memory be two
records, one for each half, allocated contiguously, with each part
aligned on whatever natural word boundary the compiler already uses.
With this layout, record copy is equally efficient as the existing
case (except, perhaps, where both lengths must be passed implicitly
for some reason).

The second consequence is its "interference" with representation
clauses.  With an arbitrary record layout, let's just assume which
includes bit fields, you'd need to generate a read-lvalue/mask-with-
rvalue/write sequence to substitute for a straight copy.  It's more
code, and it might be tricky to get working perfectly, but there's
nothing particularly mysterious about it.  I'd guess this is where the
heavy lifting is.

The third consequence is that record extensions would require multiple
block memory copies.  That means more internal accounting and some
extra code size.

> > 4) Derived limited types.  [...]
> For tagged types, it would lead to a mess because you could use the
> class-wide root type to copy limited extension components. (And if you try
> to ban such components, you're going to have to break privacy.)

I'll save this discussion for another day.  I don't consider my
thoughts about it sufficiently well-formed yet for a proper
discussion.

Eric