Chapel: Should we reserve 'init', 'init=', or 'deinit' as keywords?

[benharsh]

It might be a bit odd to reserve these when they're mainly just method names, but 'init=' is odd enough to warrant the discussion (and 'init'/'deinit' by association).

[benharsh]

@bradcray , @vasslitvinov : we can continue our offline discussion here.

[bradcray]

With a quick look, it appeared that Swift reserves init and deinit.

Vass pointed out that they are not explicitly called by the user (which also might suggest reserving them), except that I suppose they are in contexts like super.init() or this.init(), right? (but even then, maybe they can only be used in combination with certain keywords? e.g., do we (want to) support ref x = this; x.init()?)

[vasslitvinov]

To me, init and deinit are in the same boat as this, these, int, false. They are identifiers and the user cannot define them.

[e-kayrakli]

In other contexts I mentioned that I am always on the side of reserving keywords, and I think the same way for init, init=, deinit. Because:

• I don't see them as very useful in other contexts. i.e. why would an application need a variable named init?

• Even if that was allowed, I'd find application code that uses init in another purpose confusing enough to ask the question why wasn't this reserved in the first place.

@bradcray --

I am not sure we'll be losing something if we do not support ref x = this; x.init(). Moreover, isn't it a bit different than reserving the keyword? I mean we can still allow the user to call init explicitly if there is a compelling reason to do so, and at the same time prevent them to be defined by the user.

[bradcray]

I am not sure we'll be losing something if we do not support ref x = this; x.init().

In asking, I was worried that if we did support it, we'd open up a can of worms because currently the compiler looks for calls to this.init() and super.init() and does special things with them. I was worried that if we were to support arguably equivalent forms of calling them it might complicate the implementation unnecessarily (and the ability of a user to understand the code?).

we can still allow the user to call init explicitly if there is a compelling reason to do so, and at the same time prevent them to be defined by the user.

I suppose that's true.

[mppf]

If you left the decision entirely in my hands, I probably would not reserve init or deinit since these are primarily used as method names (rather than as something one can call) as was pointed out earlier. I.e. I don't see a chance for confusion with a variable var init: bool; in most contexts. However I am OK with reserving them, especially if Swift does so.

In the future, we may need to (in some very special cases) allow the user to more or less call init explicitly in something kindof like "placement new". Another strategy here is to rely on a "move" operator, which doesn't have the same impact regarding the keyword. But anyway I don't think this changes the picture much because we already have this.init() and super.init().

[lydia-duncan]

It doesn't seem to have been mentioned here, but we should also note that deinit can be used for module deinitialization, and we have toyed with allowing init for module initialization. With that in mind, the situations where init/deinit can be used other than in ways we have defined as part of the language dwindles significantly