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


Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@dicebot.lv


--- Comment #10 from Dicebot <public@dicebot.lv> 2013-10-31 07:48:57 PDT ---
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.

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

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



--- Comment #11 from Dicebot <public@dicebot.lv> 2013-10-31 07:50:47 PDT ---
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.

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

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


Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pro.mathias.lang@gmail.com


--- Comment #12 from Mathias LANG <pro.mathias.lang@gmail.com> 2013-10-31 10:08:55 PDT ---
Why should we enforce this ? We enforce things to prevent obvious mistakes. D language plays well in this field. It ensures what it is sure needs to be ensured, and give you the tools to build your own rules, with the least burdens.

It's not a mistake to have a source file with an arbitrary extension, or no extension at all. DMD will still now it's argument is a source file, whatever its name is. And they're some valid use cases where you would not want a .d[i] extension, as eles noticed in the quoted comment above, and in the NG.

(In reply to comment #9)
> Having a standard extension for D code is useful for programs like "cloc" that count lines of code, with editors that open .d files with correct D colorization, for my scripts that select files with .d suffix to test incompatibilities across different compiler versions. I have testing scripts that test .d files differently from .py files looking in directories. And it's not just a matter of my own code, it also mattes from D libraries from other people.

As you point, there are also some use cases where some tool require a specific
extension. But that's none of our business, the tool should ensure it, not DMD.
The real problem for those tools is to know what the file holds. We don't have
such problems with DMD.
For the record, good editors solve the problem easily, like vim or emacs:
# vim: syntax=d ts=4 sw=4 sts=4 sr noet
# -*- d-mode -*-

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

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



--- Comment #13 from Leandro Lucarella <leandro.lucarella@sociomantic.com> 2013-10-31 10:50:57 PDT ---
I quickly tried to implement this by only disabling the extension checks when the `-run` option is passed, but I failed miserably because the automatic extension appending is some deeply in the module code, and then object.d isn't found because the .d isn't added to the module name.

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

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



--- Comment #14 from Leandro Lucarella <leandro.lucarella@sociomantic.com> 2013-10-31 11:38:36 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2700

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

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



--- Comment #15 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-31 12:08:58 PDT ---
(In reply to comment #12)
> Why should we enforce this ? We enforce things to prevent obvious mistakes. D language plays well in this field. It ensures what it is sure needs to be ensured, and give you the tools to build your own rules, with the least burdens.
> 
> It's not a mistake to have a source file with an arbitrary extension, or no extension at all. DMD will still now it's argument is a source file, whatever its name is.

That's not true. It can't have a .lib extension, or an .obj/.o extension.

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.

(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:

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Overall-Options.html:

file.c
    C source code that must be preprocessed.
file.i
    C source code that should not be preprocessed.
file.ii
    C++ source code that should not be preprocessed.
file.tcc
    C++ header file to be turned into a precompiled header or Ada spec.

See what I mean?

If it's only .d/.di and for [1] extensionless files we allow then we make everything simple.

> 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? 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.

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

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

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



--- Comment #16 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-31 12:14:39 PDT ---
(In reply to comment #12)
> For the record, good editors solve the problem easily, like vim or emacs:
> # vim: syntax=d ts=4 sw=4 sts=4 sr noet
> # -*- d-mode -*-

You call that a solution? Arbitrary tools adding an arbitrary amount of HEADER information they've invented? So then other tools have to be able to interpret these lines too. This doesn't scale. It's not a solution.

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

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



--- Comment #17 from Dicebot <public@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: -------

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



--- Comment #18 from Leandro Lucarella <leandro.lucarella@sociomantic.com> 2013-11-01 07:56:44 PDT ---
(In reply to comment #16)
> (In reply to comment #12)
> > For the record, good editors solve the problem easily, like vim or emacs:
> > # vim: syntax=d ts=4 sw=4 sts=4 sr noet
> > # -*- d-mode -*-
> 
> You call that a solution? Arbitrary tools adding an arbitrary amount of HEADER information they've invented? So then other tools have to be able to interpret these lines too. This doesn't scale. It's not a solution.

Just a comment about this, even when is irrelevant to my proposed solution:

You only need to add extra information when you depart from the default. Is like D itself. Do you need to write all your code in ASM? No, but when you need it is there. It will be painful and you won't get lots of features, but you can do it. You are a grown up and know what's best for you.

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