[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P3

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #22 from hst...@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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #21 from ag0aep6g  ---
(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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #20 from ag0aep6g  ---
(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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #19 from Mike Parker  ---
(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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #18 from RazvanN  ---
(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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #17 from ag0aep6g  ---
(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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #16 from Mike Parker  ---
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[])`.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #15 from ag0aep6g  ---
(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?

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Parker  changed:

   What|Removed |Added

 CC||aldac...@gmail.com

--- Comment #14 from Mike Parker  ---
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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #13 from ag0aep6g  ---
(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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #12 from RazvanN  ---
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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||spec

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #11 from anonymous4  ---
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.

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #10 from hst...@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.

--

[Issue 1985] import expression should return ubyte[] not string

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|D1  D2 |D2

--

[Issue 1985] import expression should return ubyte[] not string

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail]

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


d...@dawgfoto.de changed:

   What|Removed |Added

 CC||d...@dawgfoto.de
   Platform|x86 |All
Version|1.028   |D1  D2
 OS/Version|Windows |All


--- Comment #9 from d...@dawgfoto.de 2012-05-27 03:16:35 PDT ---
UTF validation and conversions can be done at compile time,
although the interpreter is currently a little slow for this.

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