On Thu, 20 Sep 2018 at 11:58, Nikita Popov <nikita....@gmail.com> wrote:
> I do not consider it advisable to require a null initialization as a > "first iteration" of the proposal. Regardless of what our intention might > be, the effect of such a restriction will not be "I'm not going to type > this property for now, because non-nullable types are not supported", it's > going to be "I'll give this a nullable type even though it isn't, because > that's better than no type at all." Use of nullable types where they are > not necessary would be a disastrous outcome of this proposal. > This, ultimately, is where we disagree. To me, the "non-nullable types" this proposal provides are non-nullable in name only, and using them does little more than adding a comment saying "I promise this won't be null". Encouraging people to use them gives them a false guarantee, and allowing them to do so prevents us adding a stricter version of the feature later. > To move this discussion forward in a productive direction, we need a > concrete, detailed proposal of how enforcement of initialization should > work, while being compatible with secondary requirements. > It feels to me that many of the "secondary requirements" are actually separate problems which should be seen as pre-requisites, rather than constraints. The lazy initialization pattern seems to be a hack around lack of better support for property accessors. The mention of serializers needing custom methods of initialisation reminded me of the occasional discussion of better replacements for Serializable and JsonSerializable. And so on. Fixing that list of pre-requisites would obviously take time, which is why I wanted to buy that time by releasing initialised-only type hints first, and working towards a greater goal. However, I've probably beaten this drum long enough. I will hope to be wrong, and that making things stricter will still be possible later. Regards, -- Rowan Collins [IMSoP]
