| |
 | Posted by Vladimir Panteleev |  Permalink Reply |
|
Vladimir Panteleev 
| https://issues.dlang.org/show_bug.cgi?id=13491
Vladimir Panteleev <thecybershadow@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |---
--- Comment #5 from Vladimir Panteleev <thecybershadow@gmail.com> ---
OK, I am going to reopen this, because that is BULLSHIT.
(In reply to Walter Bright from comment #4)
> 1. the ordering of files presented to dmd matters - wildcards do not specify an order
This is not much more of a problem than with other languages. Yes, the first filename is special. It dictates the name of the output executable. This is not a problem! This is why we have -of. "gcc -o program *.c" is a common pattern and there's no reason why it wouldn't apply to D.
And if you're talking about the problem where DMD puts one template instantiation or whatever in whatever object file comes first on the command line - that is an ugly implementation wart that has been causing nothing but trouble to build systems since forever and needs to be fixed, not treated like a feature!
> 2. directories under development tend to accumulate detritus in the form of other source files. With a lot of files in a directory it'll be difficult to notice if one or more extra ones are there.
"detritus in the form of other source files" does not appear out of nowhere - maybe you have a habit of creating junk source files along with real ones, but many programmers don't. Many build systems already enumerate all D files in a "src" directory and compile them together. You know, like Dub, the package manager we've accepted as D's official one. If this is acceptable for all the people and projects listed on http://code.dlang.org/ , it should be acceptable for DMD users, too.
> It's hard enough keeping the junk out of git directories
Bullshit. If anything, source control makes it much easier to keep junk out. With "git status" you see any unversioned files you've created, and they stand right out in any GUI. Maybe you find it "hard enough keeping the junk out of git directories", but as we've seen, you keep coming up with innovative ways to use git that are overcomplicated, outright broken, or even dangerous, or so I'm not surprised.
> 3. D doesn't allow:
> import std.*;
> for similar reasons.
Maybe that's because wildcard import in D works completely different than in Java, C#, ActionScript, or all the other languages where it IS supported! A wildcard import in those languages DOES NOT import all the source files in that directory! It just adds that directory to the symbol search path. This works for those languages because they allow only one top-level declaration per file, and it must have the same file name as the file! So whenever the compiler encounters an unknown symbol, it checks all wildcard import paths for the presence of a file with the same name as that symbol.
> tl;dr wildcards to dmd are sloppy, error-prone, and have unpredictable behavior.
Walter Bright, time and time again, you have tried to keep all usability features out of DMD that do not conform to your 80's workflows. Column numbers in error messages; colored error output; and now this. And guess what? Time and time again, after the feature does get in, everyone praises it once it appears in the changelog. I am really tired of these arguments, and having the project leader repeatedly WONTFIX-ing a common-sense usability thing is getting really old really fast.
Further arguments:
1. On POSIX, wildcard expansion is done from the shell. So half of DMD users already have and can use wildcard expansion, whether you want it or not.
2. Commands and build instructions written by people on POSIX are not going to work for Windows users. Supporting wildcards on Windows will improve cross-platform usability of DMD.
3. LDC on Windows already supports it. The current GDC release does not support it because it was built without --enable-wirdcard - fairly sure this is an unintentional omission because the MinGW compiler builds do support this.
4. It is a simple patch. Naturally it only needs to be done on Windows.
--
|
