4 ms·

Sounds pretty good. But i think the mode selector has to be in the source code where a reader can see it, which rules out a compiler switch. The current propos

by twic 2y ago

Sounds pretty good. But i think the mode selector has to be in the source code where a reader can see it, which rules out a compiler switch. The current proposal doesn't exclude this possibility in the future, does it. Maybe one day you will be able to declare a class public class! MyClass { or have a package-info file which says package! com.initech.accounting;

layer8 2y ago
The compiler switch would be for emulating (or for disabling) the global switchover that we want to take place at some point. We currently have the wrong default, so to speak, and we’d want to change that at some point. Then it is useful to already be able to do that in earlier releases, and also to be able to revert to the old default in later releases. Otherwise, I agree that the indication should be in the source, at least during the transitional years. In practice, looking for the presence or absence for T? vs. T! will be a good heuristic for whether the code assumes the new or the old semantics. The compiler could also warn or even error out when the code is obviously being compiled with the wrong semantics, that is, if ? or ! are present but all redundant. Regarding the class syntax, you can have multiple (package-private) classes in the same file, so I wouldn’t do that. A simple solution would be to have an optional ! or ? at the very start of the source file (ignoring comments and whitespace), which means a regex could handle it (useful for external tooling), and it would also work in the absence of a package declaration (i.e. in the default package). Another reason to not put it on the package declaration is that it isn’t meant to apply to the whole package.
emccue 2y ago
To use the terminology from JSpecify: null-marked module accounting { } Could very well be the sort of thing that comes next.

by twic 2y ago

layer8 2y ago

The compiler switch would be for emulating (or for disabling) the global switchover that we want to take place at some point. We currently have the wrong default, so to speak, and we’d want to change that at some point. Then it is useful to already be able to do that in earlier releases, and also to be able to revert to the old default in later releases. Otherwise, I agree that the indication should be in the source, at least during the transitional years. In practice, looking for the presence or absence for T? vs. T! will be a good heuristic for whether the code assumes the new or the old semantics. The compiler could also warn or even error out when the code is obviously being compiled with the wrong semantics, that is, if ? or ! are present but all redundant. Regarding the class syntax, you can have multiple (package-private) classes in the same file, so I wouldn’t do that. A simple solution would be to have an optional ! or ? at the very start of the source file (ignoring comments and whitespace), which means a regex could handle it (useful for external tooling), and it would also work in the absence of a package declaration (i.e. in the default package). Another reason to not put it on the package declaration is that it isn’t meant to apply to the whole package.

emccue 2y ago

To use the terminology from JSpecify: null-marked module accounting { } Could very well be the sort of thing that comes next.