On 10/23/20 12:42 PM, data pulverizer wrote:
Hi all,
the `import` function allows a file to be read at compile time, which
opens up great opportunities for (mostly binary) file IO, where data
types can be coded into files - the user doesn't need to know data types
ahead of time. As specified in my old blog article:
https://www.active-analytics.com/blog/reading-idx-files-in-d/.
Binary files can be very large and reading the whole file at compile
time is often unnecessary.
This isn't exactly the intended use for the function, but there it is.
Since compile time read capability already exists and is useful, adding
capability to be able to read only a portion of the file at compile time
in a given location is advantageous and has utility.
For me it's not make-or-break, it just something very useful and I think
has clear use case. Please let me know if there are aspects or
alternatives I am missing.
I see no reason why the compiler can't do something special with:
enum slicedFile = import("foo.bin")[0 .. 100];
One thing that comes to mind -- most OSes support memory-mapped files.
If import simply did a memory mapped file internally, and duplicated the
string once actually used somewhere, then you can avoid full reading of
the data until it's necessary.
-Steve
