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

[d-bugmail at puremagic.com]

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

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

--