[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