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

--- Comment #17 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Mike Parker from comment #16)
> 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.

I don't care what you call it. My "workaround" is your "that's just way to do it". Point is: Having another way to get the desired type doesn't justify `import(...)` returning the other one. This goes both ways. Returning string or ubyte[] has to be justified in other ways.


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

Age ("it's been that way for years") is not a reason to not fix an issue.

We're still left with breakage as the one reason to not fix this. And that's a vague one. You guys either "have no idea" how widely it is used, or you (RazvanN) believe that it is not used widely. On what basis do you assert that breakage would be too large?

As I see it, RazvanN has been looking for old issues that can be closed easily. And now you're working backwards to justify the questionable decision.


> 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[])`.

I can't say I like it, but it looks like a workable compromise. Special-casing
`cast(...) import(...)` in the spec could also work.

--

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

--- Comment #18 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to ag0aep6g from comment #17)
> (In reply to Mike Parker from comment #16)

> I don't care what you call it. My "workaround" is your "that's just way to do it". Point is: Having another way to get the desired type doesn't justify `import(...)` returning the other one. This goes both ways. Returning string or ubyte[] has to be justified in other ways.
> 
> 

> 
> Age ("it's been that way for years") is not a reason to not fix an issue.
> 

This is not a bug, as the spec is perfectly clear on what an import expression returns [1]. It is at most an enhancement report.

[1] https://dlang.org/spec/expression.html#import_expressions

> We're still left with breakage as the one reason to not fix this. And that's a vague one. You guys either "have no idea" how widely it is used, or you (RazvanN) believe that it is not used widely. On what basis do you assert that breakage would be too large?
> 

I haven't seen a single use of it in 5 years of roaming around D repos. That doesn't mean it is not used at all. It means that it is an obscure feature, for which there are more flexible alternatives. Therefore, changing this amounts to making a low impact change that risks on breaking some code for (as much as I can tell) no benefit at all.

> As I see it, RazvanN has been looking for old issues that can be closed easily. And now you're working backwards to justify the questionable decision.

Adding a fix for this in the compiler is a trivial task. That is not the point here, but rather not to change something that has low impact, has library alternatives and might be used by people as is.


> 
> 
> > 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[])`.
> 
> I can't say I like it, but it looks like a workable compromise.
> Special-casing `cast(...) import(...)` in the spec could also work.

The spec is perfectly clear that a string literal is returned.

--

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

--- Comment #19 from Mike Parker <aldacron@gmail.com> ---
(In reply to ag0aep6g from comment #17)

> Age ("it's been that way for years") is not a reason to not fix an issue.

Perhaps if the issue is a bug, e.g., unintended behavior, but that is not the case here. The longer a feature has existed, working as intended, the bigger the chance people will have come to depend on it.

> 
> We're still left with breakage as the one reason to not fix this. And that's a vague one. You guys either "have no idea" how widely it is used, or you (RazvanN) believe that it is not used widely. On what basis do you assert that breakage would be too large?

I didn't say it would be large. I said there is a *potential* for breakage, and that's based on the fact that the feature has been around for a very long time. I know that Walter and Atila generally don't want to break code unless there is a strong benefit to doing so. The fact that .representation is available minimizes the benefit.

So the onus is on someone who wants this feature badly enough to come up with a benefit that justifies the potential breakage and outweighs the existing alternatives. That goes for changing any existing feature.

> 
> As I see it, RazvanN has been looking for old issues that can be closed easily. And now you're working backwards to justify the questionable decision.

I'm not "working backwards". I genuinely believe it shouldn't be changed.

Regardless, it's ultimately not up to me and Razvan. If Walter and Atila think it's a good idea, that's all that matters. I do think Razvan is justified in closing the issue, though, as I would expect this sort of change to require a DIP, a preview switch, and a deprecation cycle.

At the very least, someone should scan the dub repository to get an idea of how much this is used in the wild. And D shops should be queried on their use of it.

I've personally used it for code that's not on github (embedding an image), and I had no problem using .representation. Didn't think twice about it. I also would have no problem changing my code if the proposed change were implemented, but I know there are plenty of D users who are generally averse to any sort of breakage.

But please, if you feel strongly enough about it, take it to the forums and see what people think. Walter and/or Atila would probably weigh in on such a discussion.

--

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

--- Comment #20 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to RazvanN from comment #18)
> (In reply to ag0aep6g from comment #17)
[...]
> > Age ("it's been that way for years") is not a reason to not fix an issue.
> > 
> 
> This is not a bug, as the spec is perfectly clear on what an import expression returns [1]. It is at most an enhancement report.

I didn't write "bug", I wrote "issue". This issue is categorized as a bug, though. You didn't change that.

[...]
> Adding a fix for this in the compiler is a trivial task. That is not the point here, but rather not to change something that has low impact, has library alternatives and might be used by people as is.

There is a difference between prioritizing high impact changes and outright refusing to do or even accept low impact changes. The former is fine. The latter is declaring bankruptcy.

[...]
> > I can't say I like it, but it looks like a workable compromise.
> > Special-casing `cast(...) import(...)` in the spec could also work.
> 
> The spec is perfectly clear that a string literal is returned.

Yeah, we all know that. But a way to get something else would be nice.

--

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

--- Comment #21 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Mike Parker from comment #19)
> I didn't say it would be large. I said there is a *potential* for breakage, and that's based on the fact that the feature has been around for a very long time.

Ok, we're in agreement. Breakage generally gets worse with age. But age itself isn't relevant, breakage is.

[...]
> But please, if you feel strongly enough about it, take it to the forums and see what people think. Walter and/or Atila would probably weigh in on such a discussion.

I can accept avoiding breakage as the reason to close this as WONTFIX. Please note that I was the one who brought it up. RazvanN didn't mention it when closing.

I don't think either of you made a good case for closing, but I don't care enough about this issue in particular and D in general anymore to invest more energy. Note that I have not reopened the issue.

--

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

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #22 from hsteoh@quickfur.ath.cx ---
I use this feature from time to time, and I disagree that the primary use is to import modules. That's confusing it with the other use of the `import` keyword which has nothing to do with this feature, which is to read a file at compile-time and process it at compile-time. You cannot use std.file.read at compile-time, BTW.

One use case I have is to embed the contents of a file in a D program. (N.B. not to be confused with loading a file at runtime.)

Since the compiler cannot possibly tell whether a file contains text or binary data (or, for that matter, non-UTF-8 text data), it should not assume the data can be sanely interpreted as `string`. Therefore, ubyte[] is the appropriate return type, not `string`. (Though admittedly, this can be remedied with a cast to ubyte[]. It's ugly, nonetheless.)

Finally, I disagree with closing this bug simply because it's old. Walter himself often states that bugs should not be closed merely because they are old or have not been receiving attention. A bug is a bug, regardless of age or attention, and should be left open as long as the issue still exists. We should not optimizing on metrics in place of actually improving the language / compiler.  Unless Walter/Atila has explicitly decided that this issue will not be fixed, it should remain open.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3

--