www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - module(system) Identifier;

reply bearophile <bearophileHUGS lycos.com> writes:
The last changelog of D2:
http://www.digitalmars.com/d/2.0/changelog.html#new2_021

Says:

Added -safe switch and module(system) Identifier; syntax.<


I am not sure that's the best solution.
A solution that I may like is a statement (that doesn't create a new scope,
like the static if) like:

safe (...) {
}

That can be put anywhere in a module. Inside the (...) you can put a list of
various things, like array bounds safety (currently -release), pointer safety
(safeD), a possible future integer overflow safety, stack overflow safety, etc.

I don't know if that safe(){} syntax/semantics is good and doable. In
TurboPascal/Delphi/FreePascal there's something similar, so it can be doable in
D2 too.

If that syntax can't be used (for example because using a grain finer than the
whole module level is too much difficult to implement) then I think something
better than module(system) Identifier; can be invented still, that allows to
choose what safety to keep in and what not :-)

Bye,
bearophile
Dec 13 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to bearophile,


 The last changelog of D2:
 http://www.digitalmars.com/d/2.0/changelog.html#new2_021
 Says:
 

 Added -safe switch and module(system) Identifier; syntax.<
 


 I am not sure that's the best solution.



I like the idea of being able to turn on or off different checks (BTW SafeD 
is all compile time, bounds checks are runtime) but having this at the top 
of the module makes it very easy to tell what files use unsafe code.
Dec 13 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 The last changelog of D2:
 http://www.digitalmars.com/d/2.0/changelog.html#new2_021
 
 Says:

 Added -safe switch and module(system) Identifier; syntax.<


 
 I am not sure that's the best solution.


Doing it at the module level was deliberate. Not for technical reasons, 
but to make it easy for people doing quality code reviews. System 
modules should be segregated and given special attention. Having it 
dispersed throughout the code modules pretty much excludes being able to 
abstract it away properly.
Dec 13 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Doing it at the module level was deliberate. Not for technical reasons, 
 but to make it easy for people doing quality code reviews. System 
 modules should be segregated and given special attention. Having it 
 dispersed throughout the code modules pretty much excludes being able to 
 abstract it away properly.


Okay, that shots down my first idea.
But what about the second one? (That is to allow to specify a list of what to
be safe of, at the top of the module?) A possible syntax:
module(safe1, safe2, ...) Identifier;

Bye,
bearophile
Dec 14 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 (That is to allow to specify a list of what to be safe of, at the top
 of the module?) A possible syntax: module(safe1, safe2, ...)
 Identifier;


I suggest seeing how things go with just module(System) for now. It may 
prove to be plenty adequate.
Dec 14 2008
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 bearophile wrote:
 

 The last changelog of D2:
 http://www.digitalmars.com/d/2.0/changelog.html#new2_021
 Says:
 

 Added -safe switch and module(system) Identifier; syntax.<
 


 I am not sure that's the best solution.
 


 Doing it at the module level was deliberate. Not for technical
 reasons, but to make it easy for people doing quality code reviews.
 System modules should be segregated and given special attention.
 Having it dispersed throughout the code modules pretty much excludes
 being able to abstract it away properly.
 


A combination of the two might prove useful. Allow bearophile's suggestion 
but only with some variant of module(system) at the top. Files using this 
would still be easy to find but it would also (if the internal tag is easy 
to grep for) limit the lines that need to be reviewed.

Keeping the current form as well would be good.
Dec 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:

 Reply to Walter,
 

 bearophile wrote:


 The last changelog of D2:
 http://www.digitalmars.com/d/2.0/changelog.html#new2_021
 Says:


 Added -safe switch and module(system) Identifier; syntax.<


 I am not sure that's the best solution.


 Doing it at the module level was deliberate. Not for technical
 reasons, but to make it easy for people doing quality code reviews.
 System modules should be segregated and given special attention.
 Having it dispersed throughout the code modules pretty much excludes
 being able to abstract it away properly.


 
 A combination of the two might prove useful. Allow bearophile's 
 suggestion but only with some variant of module(system) at the top. 
 Files using this would still be easy to find but it would also (if the 
 internal tag is easy to grep for) limit the lines that need to be reviewed.
 
 Keeping the current form as well would be good.


IMHO it is better to keep system-fu at the module level instead of 
sprinkled all over. This is exactly a case when, counter-intuitively, 
more restrictive is better. This restrictions will help people organize 
code with few low-level modules supporting a large number of safe 
modules, instead of fostering insertion of inline unsafe things whenever 
it seems fit.


Andrei
Dec 14 2008
parent BCS <ao pathlink.com> writes:
Reply to Andrei,


 IMHO it is better to keep system-fu at the module level instead of
 sprinkled all over. This is exactly a case when, counter-intuitively,
 more restrictive is better. This restrictions will help people
 organize code with few low-level modules supporting a large number of
 safe modules, instead of fostering insertion of inline unsafe things
 whenever it seems fit.
 
 Andrei
 


That's reasonable. OTOH it could end in the "Make it all public" syndrome 
if someone just gets tired of excising the really unsafe parts. I think a 
'try the current thing and see what happens' approach will be best, for now.
Dec 14 2008