New Issue: nil initialization and type

19672, "vasslitvinov", "nil initialization and type", "2022-04-20T17:44:48Z"

This proposal addresses these questions:

  • Should this be legal: var x = nil;
  • If so, what should be the inferred type of x?
  • Should the type of nil be user-facing?
  • If so, what should we call it? how should it relate to class types?

The proposal is:

  • Disallow var x = nil;
  • Allow the user to manipulate the type of nil; write it as nil.type; have it as a subtype of all nilable class types.

The rationale:

  • If we allow var x = nil; and give x the nil type, x will be merely an alias for nil, which is not useful.
  • If we allow var x = nil; and give x the object type, as proposed and motivated in infer_nil.future (see below), then it is unclear what memory management of object it should be. Also, it is not undue hardship to require the user to specify the desired type of x explicitly.

This proposal includes retiring the following future as "won't fix":
test/classes/deitz/class/infer_nil.future

See also "The nil value" subsection in the spec

Next Steps:

  • What is the type of CTypes.c_nil ?
  • Should we allow var x = c_nil; ?
    // This declaration comes from the bug issue #19244
  • If so, what should be the inferred type of x ?