On 10/10/12 11:21, Jonathan M Davis wrote:
On Monday, October 08, 2012 18:47:43 Malte Skarupke wrote:
So I really can't think of a reason for why you wouldn't want
this. Yet this discussion has happened several times already.
There is clear demand for it and very good reasons, such as those
mentioned in all the linked discussions.

So why is this being rejected?

It buys you pretty much nothing. There are plenty of places in the language
where init is required (e.g. member variables that can't be directly
initialized and the elements in an array). So, init _will_ be used regardless
of what you do with the default constructor. If you want to prevent that, then
you need to disable init, which we can already do. But you're not going to get
those things initialized with the default constructor, which kind of defeats
the purpose of the default constructor. If you can't guarantee that every
instance which isn't explicitly constructed is default constructed, then
what's the point?

Of course there would be no point.
You have not answered the question. The issue is, WHY can we not guarantee that that the struct default constructor is called?

I have a vague memory that Walter mentioned a technical difficulty once but I don't remember anything about what it was.

I can't imagine what it would be. Even in the worst case, it would be possible to run CTFE on the default constructor in order to create .init. This would limit the default constructor to things which are CTFEable, but even that would still be useful for templated structs.

Really, there does not seem to me to be any point in having an invariant for a struct, without a default constructor.

BTW .init doesn't really work for nested structs anyway. There are several open bugs related to that.

Reply via email to