digitalmars.D - Add pragma(error) and pragma(warning) to the language.
- Tobias Pankrath (11/11) Nov 10 2011 I'm currently writing some template based code and there are
- Justin Whear (3/18) Nov 10 2011 How would pragma(error) differ from "static assert(false,
- Tobias Pankrath (2/5) Nov 10 2011 It wouldn't. I was just not aware of this possibility.
- Timon Gehr (4/6) Nov 10 2011 static assert explains that the error occured because of a static
- Xinok (3/14) Nov 10 2011 I'm not against this idea, but I'd prefer that actual compiler warnings
- Timon Gehr (4/25) Nov 10 2011 They are because the compiler gives line information (and a good error
- Gor Gyolchanyan (6/34) Nov 11 2011 Separating compiler built-in and user-space solutions is a bad idea, IMO...
I'm currently writing some template based code and there are situations, when I want to issue warnings or errors to users of my code. I know of pragma(msg), but the output will be formatted differently from the normal compiler warnings / errors. This is bad for tool integration and the messages will likely not catch the eye of a normal user. Therefore I propose to add two pragmas pragma(error) and pragma(warning) to the core language, which work just like pragma(msg), but will format the message the way, the compiler would format its own error messages or warnings. pragma(error) should cause a real compile error, too. What do you think?
Nov 10 2011
How would pragma(error) differ from "static assert(false, errorMessageHere)"? Tobias Pankrath wrote:I'm currently writing some template based code and there are situations, when I want to issue warnings or errors to users of my code. I know of pragma(msg), but the output will be formatted differently from the normal compiler warnings / errors. This is bad for tool integration and the messages will likely not catch the eye of a normal user. Therefore I propose to add two pragmas pragma(error) and pragma(warning) to the core language, which work just like pragma(msg), but will format the message the way, the compiler would format its own error messages or warnings. pragma(error) should cause a real compile error, too. What do you think?
Nov 10 2011
Tobias Pankrath <tobias pankrath.net> Justin Whear wrote:How would pragma(error) differ from "static assert(false, errorMessageHere)"?It wouldn't. I was just not aware of this possibility.
Nov 10 2011
On 11/10/2011 08:12 PM, Justin Whear wrote:How would pragma(error) differ from "static assert(false, errorMessageHere)"?static assert explains that the error occured because of a static assertion failure, pragma(error) would not do such a thing. topic: +1.
Nov 10 2011
On 11/10/2011 2:08 PM, Tobias Pankrath wrote:I'm currently writing some template based code and there are situations, when I want to issue warnings or errors to users of my code. I know of pragma(msg), but the output will be formatted differently from the normal compiler warnings / errors. This is bad for tool integration and the messages will likely not catch the eye of a normal user. Therefore I propose to add two pragmas pragma(error) and pragma(warning) to the core language, which work just like pragma(msg), but will format the message the way, the compiler would format its own error messages or warnings. pragma(error) should cause a real compile error, too. What do you think?I'm not against this idea, but I'd prefer that actual compiler warnings & errors would be distinguishable from those thrown by code.
Nov 10 2011
On 11/10/2011 08:36 PM, Xinok wrote:On 11/10/2011 2:08 PM, Tobias Pankrath wrote:They are because the compiler gives line information (and a good error message will normally be as specific as to give a good indication that it was thrown by code anyway).I'm currently writing some template based code and there are situations, when I want to issue warnings or errors to users of my code. I know of pragma(msg), but the output will be formatted differently from the normal compiler warnings / errors. This is bad for tool integration and the messages will likely not catch the eye of a normal user. Therefore I propose to add two pragmas pragma(error) and pragma(warning) to the core language, which work just like pragma(msg), but will format the message the way, the compiler would format its own error messages or warnings. pragma(error) should cause a real compile error, too. What do you think?I'm not against this idea, but I'd prefer that actual compiler warnings & errors would be distinguishable from those thrown by code.
Nov 10 2011
Separating compiler built-in and user-space solutions is a bad idea, IMO. The evolution of programming languages clearly show, that there is less and less magic in the air as they develop. Ultimately, programming languages will be reduced to a tiny tiny core and a giant ball of user-space support layers. On Fri, Nov 11, 2011 at 12:23 AM, Timon Gehr <timon.gehr gmx.ch> wrote:On 11/10/2011 08:36 PM, Xinok wrote:On 11/10/2011 2:08 PM, Tobias Pankrath wrote:They are because the compiler gives line information (and a good error message will normally be as specific as to give a good indication that it was thrown by code anyway).I'm currently writing some template based code and there are situations, when I want to issue warnings or errors to users of my code. I know of pragma(msg), but the output will be formatted differently from the normal compiler warnings / errors. This is bad for tool integration and the messages will likely not catch the eye of a normal user. Therefore I propose to add two pragmas pragma(error) and pragma(warning) to the core language, which work just like pragma(msg), but will format the message the way, the compiler would format its own error messages or warnings. pragma(error) should cause a real compile error, too. What do you think?I'm not against this idea, but I'd prefer that actual compiler warnings & errors would be distinguishable from those thrown by code.
Nov 11 2011