https://issues.dlang.org/show_bug.cgi?id=1985

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--

https://issues.dlang.org/show_bug.cgi?id=1985

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D1 & D2                     |D2

--

https://issues.dlang.org/show_bug.cgi?id=1985

--- Comment #10 from hsteoh@quickfur.ath.cx ---
The compiler has no way to know whether an imported file is even text to begin with. For all you know, the code could be:

````
auto logo = import("logo.png"); // embed image inside executable
````

It's not the compiler's job to decode the contents of arbitrary files. Let import(filename) return ubyte[], and let the user code decide what to do with it.

--

https://issues.dlang.org/show_bug.cgi?id=1985

--- Comment #11 from anonymous4 <dfj1esp02@sneakemail.com> ---
I think it's better to replace import expression with intrinsic, say, importText (like std.file.readText). This will also reduce grammar complexity and remove second and rarely used meaning from the import keyword. Due to how rarely import expression is used it confuses newcomers that are used only to it's usage as module import statement.

--

https://issues.dlang.org/show_bug.cgi?id=1985

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec

--

https://issues.dlang.org/show_bug.cgi?id=1985

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |razvan.nitu1305@gmail.com
         Resolution|---                         |WONTFIX

--- Comment #12 from RazvanN <razvan.nitu1305@gmail.com> ---
1. The primary purpose of the import keyword is to import other modules. Since its meaning is tied to importing text files, it makes sense to return a string. If you want to read files of arbitrary types, std.file.read should be used.

2. This particular semantic of the import keyword is not widely spread. I, personally, have never seen it in any of the D projects that I contributed to.

So, since this is not a widely used feature and the import semantic is tied to text file, I will close this as WONTFIX.

--

https://issues.dlang.org/show_bug.cgi?id=1985

ag0aep6g <ag0aep6g@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ag0aep6g@gmail.com

--- Comment #13 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to RazvanN from comment #12)
> 1. The primary purpose of the import keyword is to import other modules. Since its meaning is tied to importing text files, it makes sense to return a string. If you want to read files of arbitrary types, std.file.read should be used.

`import ...;` isn't tied to text files in any meaningful way. It imports a module, which may or may not be stored as text. It doesn't yield a string.

std.file.read cannot be used during compilation like `import(...)`.


> 2. This particular semantic of the import keyword is not widely spread. I, personally, have never seen it in any of the D projects that I contributed to.

I don't think you personally using a feature is a good metric for accepting issues.

--

https://issues.dlang.org/show_bug.cgi?id=1985

Mike Parker <aldacron@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldacron@gmail.com

--- Comment #14 from Mike Parker <aldacron@gmail.com> ---
This gets at the bytes, does it not?

enum bytes = import("foo.png").representation;

I don't think we should change the behavior of the import expression at this point when the above achieves the same result.

--

https://issues.dlang.org/show_bug.cgi?id=1985

--- Comment #15 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Mike Parker from comment #14)
> This gets at the bytes, does it not?
> 
> enum bytes = import("foo.png").representation;

Sure. But it only works because DMD happily creates an invalid string from `import("foo.png")` which is unusable unless reinterpreted. Arguably, it should throw an error instead.

> I don't think we should change the behavior of the import expression at this point when the above achieves the same result.

Having a workaround is not a reason to keep the current behavior.

The one argument for not addressing the issue as requested is breakage. If the type of `import(...)` is changed to ubyte[], the current uses will have to be updated. But if RazvanN's assertion that the feature isn't being used all that much is correct, then breakage doesn't matter all that much, does it?

--

https://issues.dlang.org/show_bug.cgi?id=1985

--- Comment #16 from Mike Parker <aldacron@gmail.com> ---
Using 'representation' is not a workaround, anymore than would be converting a `ubyte[]` to a string. No matter what the expression returns, it will need to be converted to the format you need it in if that isn't the one you get.

And I have no idea how often it's used in the wild. But it's been the way it is for years and it seems arbitrary to change it now. Given that we have a way to easily get a `ubyte[]` from it, I just don't see that changing its behavior is worth the potential breakage.

I do agree that an array of bytes would be more sensible, but I just think that ship has sailed. What would be interesting would be to enhance it such that a type can be specified as part of the expression. Maybe something like `import("foo.png", ubyte[])`.

--