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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Aug 3 13:17:17 UTC 2021


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

--- Comment #18 from RazvanN <razvan.nitu1305 at 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.

--


More information about the Digitalmars-d-bugs mailing list