May 20, 2007 Null keywords: Another feature D needs to replace the C preprocessor (was: Re: Why D _still_ needs the C preprocessor) | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | BCS <ao@pathlink.com> spewed this unto the Network: > Reply to Justin, > >> nobody@nowhere.nonet Wrote: >> >> It's not as sugary sweet as you may want, but you can leave off the 'delegate' keyword. >> >> OMF_Record[] results = library.select_records((OMF_Record rec) { >> return (rec.record_type == LIB_HEADER);}); >> > I can't think of any reason that the above shouldn't be reducable to > > auto results = lib.select_records((rec){return (rec.record_type == LIB_HEADER);}); > > as long as there is only one function that take a delegate that takes one argument, the type of the argument could be inferred. It would _seem_ that DMD should be able to infer the argument type, and also the number of arguments (and their names) from the prototype of select_records. That was the assumption I was making on my first attempt to write that function. Instead, DMD tries to figure out the type of the delegate in total isolation. It _ought_ to be possible to leave the (rec) out completely. I ended up using the mixin keyword to call select_records, which requires select_records to be a template, and that the query references a variable within the scope of select_records. Not the ideal solution, but not worse than other ideas, such as using lazy evaluation and an extra argument. As this thread was originally intended to argue that D still needs the C preprocessor (or more language features to prevent its resurgence), I have returned with another example, this time from code that is up for download on dsource.org (which includes its own preprocessor). The language feature that would eliminate the need for a preprocessor in this instance would be the ability to define null "keywords". Null keywords would be words that the D compiler simply ignores. They would replace preprocessor usages such as this, commonly found in C programs: #ifndef HAS_EXPORT #define export /* This D keyword is not recognized on Linux */ #endif Null keywords have to be legal anywhere that any keyword _might_ be legal, now or in the future, in DMD or any other implementation of D. The syntax for null keywords might look like this: /* Defines 'export' as a null keyword on Linux. * Causes a compilation error on Windows since * export is already a recognized keyword: */ nullword export; Here's why: I downloaded DAllegro, which implements a D binding to a game-programming library that seems to be popular among C programmers. DAllegro implements its own text preprocessor as a shell script, to account for the fact that the Linux version of DMD does not accept the "export" keyword. The shell script goes through the source and deletes every occurence of the word "export" so it'll compile. The readme.txt instructs the user to use the preprocessor only if compiling on Unix. This was apparently considered better than writing two "version" blocks every time the "export" keyword was used. A mixin template could provide another clunky solution to this problem, but there is no solution as elegant as simply being able to use the "export" keyword on Windows and define it to nothing on Linux. -- All your .signature are belong to us. Take off every 'sig' for great justice. |
Copyright © 1999-2021 by the D Language Foundation