On Wed, 2008-01-23 at 19:22 +0000, Sam Mason wrote:
> > > 1. Field p must be properly initialized to a non-null pointer
> > > before it is used.
>
> Do null pointers ever get exposed to the user? I believe Optional/Maybe
> types are to be implmented as null values, but that's not quite the same
> in my mind.
Not today. But as we move to an s-block syntax, we will want to adopt a
more C-like idiom for initialization. There is no real difference
between:
struct s { ... };
s( list-of-initializers );
vs.
s sinstance;
sinstance.fld = x;
... rest of initializations ...
And the equivalence can be determined in most real use-cases by static
analysis. In the interests of idiomatic compatibility, it would be
pleasant if we could handle this some day.
> > Is the condition is same as saying `p' must never be used as an
> > rvalue before being initialized? This condition is certainly sufficient.
>
> How well does this interact with garbage collection? It seems as
> though you're going to have things on the stack that are known to be
> uninitalised pointers. Can these be flagged to the garbage collector,
> or is the current frame special somehow?
The implementation must quasi-initialize such fields to zero to ensure
GC safety, but that since the data structure isn't well-typed until it
is more or less fully initialized, this doesn't really create a problem
for typing.
> I've just reread the message and noticed that your comments were really
> aimed at structures, does that mean you're only worried about the heap
> at the moment?
Also stack allocated cases. In BitC, a structure can be a value type.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
