www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Other kind of static assert

reply Ary Borenszweig <ary esperanto.org.ar> writes:
An example where static assert is used is, for example, at the top of a 
module to signal that the module is not available if some condition is 
not met:

---
module foo;

version(Tango) {
} else {
   static assert("Sorry, you need to use Tango with this module");
}

// rest of the code...
---

Now, imagine an IDE that wants to singal errors in that file. Obviously, 
if the user didn't define "Tango" as a version identifier, that static 
assert will be marked as an error. But it isn't really an error... The 
file contains no errors. The error just exists when that particular 
module is used with the "wrong" version.

I was thinking maybe a pragma could be added instead of a static assert:

---
module foo;

version(Tango) {
} else {
   pragma(moduleUnavailable, "Sorry, you need to use Tango");
}
---

and the compiler would print "Moudle foo unavailable: Sorry, you need to 
use Tango". (note: the pragma name is the first one that came into my 
mind, please just discuss the idea :-))

An IDE could just ignore those pragmas and stop signaling errors for 
that module.

I know, the possibility of some feature being introduced in the language 
just because of an IDE need must be zero, I just wanted to know what you 
think about this. Maybe the intention is also clearer (again, it's not 
an error, the module is unavailable).
May 19 2008
next sibling parent Lutger <lutger.blijdestin gmail.com> writes:
What is the benefit above pragma(msg, ...)?

I'm not sure it's a bad thing the IDE points this out as an error. When
you're looking at this module it is likely that you are going to use it and
then you want to know that you have set up the version identifiers wrong.
Otherwise you'll have to compile to know about it, I think that letting the
IDE signal it as an error in the context of your project is quicker.
May 20 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:
 An example where static assert is used is, for example, at the top of a 
 module to signal that the module is not available if some condition is 
 not met:
 
 ---
 module foo;
 
 version(Tango) {
 } else {
   static assert("Sorry, you need to use Tango with this module");
 }
 
 // rest of the code...
 ---
 
 Now, imagine an IDE that wants to singal errors in that file. Obviously, 
 if the user didn't define "Tango" as a version identifier, that static 
 assert will be marked as an error. But it isn't really an error... The 
 file contains no errors. The error just exists when that particular 
 module is used with the "wrong" version.
 
 I was thinking maybe a pragma could be added instead of a static assert:
 
 ---
 module foo;
 
 version(Tango) {
 } else {
   pragma(moduleUnavailable, "Sorry, you need to use Tango");
 }
 ---
 
 and the compiler would print "Moudle foo unavailable: Sorry, you need to 
 use Tango". (note: the pragma name is the first one that came into my 
 mind, please just discuss the idea :-))
 
 An IDE could just ignore those pragmas and stop signaling errors for 
 that module.
 
 I know, the possibility of some feature being introduced in the language 
 just because of an IDE need must be zero, I just wanted to know what you 
 think about this. Maybe the intention is also clearer (again, it's not 
 an error, the module is unavailable).
I don't see how this is better than a static assert. An error condition has been reached, so why not mark it as such. Something which specified exactly what was needed to get it to compile would be better, i.e. pragma(requireVersion, Tango); The IDE could then have a quick fix like "add Tango to active version identifiers"
May 20 2008
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ok, Tango is a bad example. I have other examples:

1. If you are developing Tango, you have the tango.stdc.posix.phtread 
module. Now, if neither the "linux" nor the "darwing" versions are 
defined, you'll get errors, because you can find declarations such as:

int pthread_attr_destroy(pthread_attr_t*);

which will give an error because pthread_attr_t is only defined if 
"linux" or "darwing" are defined. Now, that's not a fair error. The 
module can't be used without any of those versions. Is that really an 
error? Is there something wrong that must be fixed? No.

2. Module win32.accctrl in the bindings project. At the top of the file 
you can find:

static assert (_WIN32_WINNT_ONLY,
	"win32.accctrl is available only if version WindowsNTonly, WindowsXP, "
	"Windows2003 or WindowsVista is set");

Now, the project as a whole may be used with other versions that those 
in the static assert. In fact, there may exists other modules that, to 
be used, must have defined other versions. So either way you'll get an 
error. But, again, it's not really an error. It's just pointing out that 
the module won't work if some condition is not met, not that some 
assertion in the module's logic failed.
May 20 2008