[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=11365



--- Comment #17 from Dicebot <public at dicebot.lv> 2013-10-31 13:27:13 PDT ---
(In reply to comment #15)
> That's not true. It can't have a .lib extension, or an .obj/.o extension.

This is purely a problem of how DMD argument list is designed, not meaningful
limitation. And yet another example of what apps shouldn't do.

> Arbitrary extensions means import switches will not work, the compiler won't
> know which files it has to inspect to find D code. So this feature will be
> useful for scripts and in cases where you're explicitly passing all files to
> DMD.

Exactly. And someone who wants to use arbitrary extensions will be aware that
he is stepping aside from common naming convention and thus losing some
convenience offered by compiler. It is perfectly expected.

> (In reply to comment #10)
> > As I have already mentioned in NG, the very idea that file extension should
> > have any relation with its content is just plain wrong and needs to be
> > discouraged, as well as any arbitrary limitations that may impose.
> 
> That's exactly what happens when you allow arbitrary extensions, tools end up
> inventing their own semantics *based on* the extension:
> ...
> See what I mean? 

It is exactly what happens when _someone_ (compiler, tools, whatever) decides
to strictly couple some behavior exclusively to extension. See what I mean? :)

> > In other words, it is not a as much of a problem of DMD codebase that is uses
> > ".c" for C++ code, it is a problem of IDE's/tools that assume it is a C code
> > without providing any convenient way to override that assumption.
> 
> So now every tool in existence has to do heuristics on text files? 

Yes if it is important (there are standard tools for that like famous "file"
command). In most cases though it should just try interpret input as if it is
legal file and fail in process if it has garbage. Similar to how it will fail
if you put garbage into .d file. And context of interpretation should be
defined by compiler switches, configuration files or some other external thing.
Using default interpretation defined by convention like file extension is also
fine if it can be overridden with a manual option.

> The benefit
> of having known and defined extensions is to make it easier to figure out what
> a file is without having to open it, to make it easier to filter through a
> directory of files and organize them based on their extension.

As I have said, crazy DOS legacy. Luckily, most Linux file managers don't do
this and actually explore file metadata.

> Using .c for C++ files is Walter's fault and nobody else's. There are no
> excuses here.

There are no excuses but there is also no disaster. It is bad to break common
practice but any sane IDE will allow to trivially configure mapping of .c files
to C++ semantics. Just as they should do.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------