import(__FILE_LITERAL__)

Sep 09

monkyyy

Sep 09

Daniel N

Sep 09

Sep 09

Sep 09

Sep 09

Import Expressions are limited and had to use in abstractions because they require the user to pass -J=., which given the average d user uses dub; suggesting such a thing requires a 3 step process.

Note that by default an import expression will not compile unless one or more paths are passed via the -J switch. This tells the compiler where it should look for the files to import. This is a security feature.

My opinion on the subject may violate the dip forum guidelines.

I suggest that its safe to read the file the user is compiling during compilation. I suggest that new special token that generates ... something that an import expression can take without a -J=..

import foo;//lolz
import std;
enum string=import(__FILE_LITERAL__).split('/n').front;// "import foo;//lolz"

By separating it into two step process you could use the special token magic
void foo(alias file=__FILE_LITERAL__,int line=__LINE__)(){

On Monday, 9 September 2024 at 18:18:31 UTC, monkyyy wrote: > Import Expressions are limited and had to use in abstractions because they require the user to pass `-J=.`, which given the average d user uses dub; suggesting such a thing requires a 3 step process. > >> Note that by default an import expression will not compile unless one or more paths are passed via the -J switch. This tells the compiler where it should look for the files to import. This is a security feature. > > My opinion on the subject may violate the dip forum guidelines. > > --- > > I suggest that its safe to read the file the user is compiling during compilation. I suggest that new special token that generates ... something that an import expression can take without a `-J=.`. > > ```d > import foo;//lolz > import std; > enum string=import(__FILE_LITERAL__).split('/n').front;// "import foo;//lolz" > ``` > > By separating it into two step process you could use the special token magic > `void foo(alias file=__FILE_LITERAL__,int line=__LINE__)(){` I think that would work but I have two details in mind 1. should it be expanded to a relative or absolute path ? Remember why __FILE_FULL_PATH__ was created. 2. that feature means leaking the file in plain text. And finally, what's the use of that feature, maybe allow to program a compile-time Quine, but what else ? In D reflexion is supposed to work with `__traits`.

September 09

Re: import(__FILE_LITERAL__)

Posted by monkyyy
in reply to Daniel N

Permalink

monkyyy

Posted in reply to Daniel N

Permalink

On Monday, 9 September 2024 at 19:00:32 UTC, Daniel N wrote:

On Monday, 9 September 2024 at 18:18:31 UTC, monkyyy wrote:

I suggest that its safe to read the file the user is compiling during compilation. I suggest that new special token that generates ... something that an import expression can take without a -J=..

import foo;//lolz
import std;
enum string=import(__FILE_LITERAL__).split('/n').front;// "import foo;//lolz"

By separating it into two step process you could use the special token magic
void foo(alias file=__FILE_LITERAL__,int line=__LINE__)(){

I like this idea, I had the same need, although wouldn't it work with parameterless import?

import()

Special token sequences are a major source of magic, my compile time counter pattern uses __LINE__ for example

Fundamentally if you want a template to be de-auto-memoized, your probably putting in a a token sequence in the header

On Monday, 9 September 2024 at 19:33:38 UTC, user1234 wrote: > > And finally, what's the use of that feature, maybe allow to program a compile-time Quine, but what else ? https://forum.dlang.org/post/ejkrtibofyeyadrzxgkg@forum.dlang.org for starters, debugging information without ugly trade offs; alternatives to my `__HERE__` post that no one liked, etc. > In D reflexion is supposed to work with `__traits`. and if it fails, or is just slower then what I can parse in 3 seconds of string manipulation?

On Monday, 9 September 2024 at 20:04:36 UTC, monkyyy wrote: > On Monday, 9 September 2024 at 19:33:38 UTC, user1234 wrote: >> >> And finally, what's the use of that feature, maybe allow to program a compile-time Quine, but what else ? > > https://forum.dlang.org/post/ejkrtibofyeyadrzxgkg@forum.dlang.org > > for starters, debugging information without ugly trade offs; alternatives to my `__HERE__` post that no one liked, etc. > >> In D reflexion is supposed to work with `__traits`. > > and if it fails, or is just slower then what I can parse in 3 seconds of string manipulation? Yeah you can ignore the remark about __traits. It was because I didn't see the use so I supposed it was eventually to perform some kind of introspection based on parsing, which does not appear to be the motivation.

Forums