@shallow for data and constructor declarations

[fmease]

The attribute @shallow switches from the default mode of creating a namespace containing subordinate declarations to placing those into the same namespace where the original declaration is defined in.

It is semver compatible (here i.e. not a major change) for an API to go from a non-shallow data declaration to a shallow one if all constructors are (manually) used in the same module and the same exposure scope of the data type. Starting out with non-shallow is thus forward compatible. The reverse is not given. Neither direction is given for (non-)shallowness on constructors since one cannot use inside of the constructor listing.

Motivation

Less to type esp. when prototyping since one does not need to qualify paths as much or need to use them. No other reason. Therefore, it is quite low priority and might not even become part of the language at all.

Scope

• on data declarations
• on constructor declarations

[fmease]

Resolution: Not worth adding. Creates "two ways of doing things" and makes the name resolver a tiny bit more complex for such an edge case feature. Alternative: "use all" (in turn not part of the language but a proposal) (e.g. use Data._) which is only allowed in protoyping mode (if ever added).