Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
module(safe) is not a comment. We need three types of modules
because of the interaction between what the module declares and what
the command line wants.
Let's assume the default, no-flag build allows unsafe code, like
right now. Then, module(safe) means that the module volunteers
itself for tighter checking, and module(system) is same as module
unadorned.
But then if the user compiles with -safe, module(safe) is the same
as module unadorned, and module(system) allows for unchecked
operations in that particular module. I was uncomfortable with this,
but Walter convinced me that D's charter is not to allow sandbox
compilation and execution of malicious code. If you have the
sources, you may as well take a look at their module declarations if
you have some worry.
Regardless on the result of the debate regarding the default
compilation mode, if the change of that default mode is allowed in
the command line, then we need both module(safe) and module(system).
When would it be MANDATORY for a module to be compiled in safe mode?
module(safe) entails safe mode, come hell or high water.
If module(safe) implies bound-checking *cannot* be turned off for
that module, would any standard library modules be module(safe)?
I think most or all of the standard library is trusted. But don't
forget that std is a bad example of a typical library or program
because std interfaces programs with the OS.
I think it's not so atypical. Database, graphics, anything which calls a
C library will be the same.
I still think the standard library is different because it's part of the
computing base offered by the language. A clearer example is Java, which
has things in its standard library that cannot be done in Java. But I
agree there will be other libraries that need to interface with C.
For an app, I'd imagine you'd have a policy of either always compiling
with -safe, or ignoring it.
I'd say for an app you'd have a policy of marking most modules as safe.
That makes it irrelevant what compiler switch is used and puts the onus
in the right place: the module.
If you've got a general-purpose library, you have to assume some of your
users will be compiling with -safe. So you have to make all your library
modules safe, regardless of how they are marked. (Similarly, -w is NOT
optional for library developers).
If you've got a general-purpose library, you try what any D codebase
should try: make most of your modules safe and as few as possible system.
That doesn't leave very much.
I'm not seeing the use case for module(safe).
I think you ascribe to -safe what module(safe) should do. My point is
that -safe is inferior, just some low-level means of choosing a default
absent other declaration. The "good" way to go about it is to think your
design in terms of safe vs. system modules.
Andrei
