Provide rationale for defaultability

[wingo]

It seems that defaultability is an unneeded wrinkle -- it's always known when allocating a struct which fields will have default values, and they can just be given in the source program. I can only think that defaultability is a space-saving measure; but is it that important? If so, consider augmenting the spec to indicate the rationale for this feature.

[rossberg]

The existing numeric types are defaultable today (for locals), so there has to be at least a minimal notion of defaultability and corresponding type distinction. And once that exists, there doesn't seem to be a strong reason not to introduce the natural extension to new types. As you observe, it can save some space.

[wingo]

I think I missed the defaultability aspect of the existing types. Given that, I think it's just my ignorance and no more words need be spent :) Closing this bug.

[titzer]

I actually agree with @rossberg-chromium, but there might be design alternatives that allow us to add types that do not have default values. E.g. non-default values might be crucial if we add sum types later.

To motivate us to explore such design alternatives, I think we should reopen this issue--but just to add a blurb that explains the current rationale (if nothing more than a TODO to think this through a bit later).

[rossberg]

@titzer, not sure what exactly you are suggesting. The proposal already states that both defaultable and non-defaultable types exist.

[titzer]

Sorry, yes, I realized this after posting the comment above.

[binji]

Seems like this issue was addressed, closing.