https://issues.dlang.org/show_bug.cgi?id=1985
--- Comment #18 from RazvanN <[email protected]> --- (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. --
