Jump to page: 1 2
Thread overview
Grouped named import
Jul 22
ryuukk_
Jul 22
ryuukk_
Jul 22
ryuukk_
Jul 22
ryuukk_
Jul 22
Dennis
Jul 23
ryuukk_
DIP CLOSED
Jul 23
Dennis
July 22

Saw this somewhere, and to be honest, that's something i always wanted to be able to do

That may be something i could try to implement, sounds relatively easy

import c = sqlite3, miniz;

https://dlang.org/spec/module.html#renamed_imports

July 22

On Monday, 22 July 2024 at 11:23:51 UTC, ryuukk_ wrote:

>

Saw this somewhere, and to be honest, that's something i always wanted to be able to do

That may be something i could try to implement, sounds relatively easy

import c = sqlite3, miniz;

https://dlang.org/spec/module.html#renamed_imports

Is it equivalent to this?

import c = sqlite3;
import miniz;

If yes, this requires no DIP. But honestly, the reason why D requires separate import statements for renaming stuff is that it’s much clearer.

July 22

On Monday, 22 July 2024 at 12:06:52 UTC, Quirin Schroll wrote:

>

On Monday, 22 July 2024 at 11:23:51 UTC, ryuukk_ wrote:

>

Saw this somewhere, and to be honest, that's something i always wanted to be able to do

That may be something i could try to implement, sounds relatively easy

import c = sqlite3, miniz;

https://dlang.org/spec/module.html#renamed_imports

Is it equivalent to this?

import c = sqlite3;
import miniz;

If yes, this requires no DIP. But honestly, the reason why D requires separate import statements for renaming stuff is that it’s much clearer.

I just realized one can do this:

import x = std.stdio;
import x = std.file;

If that is intended, it’s especially important for clarity that separate import statements are required.

July 22

On Monday, 22 July 2024 at 12:06:52 UTC, Quirin Schroll wrote:

>

On Monday, 22 July 2024 at 11:23:51 UTC, ryuukk_ wrote:

>

Saw this somewhere, and to be honest, that's something i always wanted to be able to do

That may be something i could try to implement, sounds relatively easy

import c = sqlite3, miniz;

https://dlang.org/spec/module.html#renamed_imports

Is it equivalent to this?

import c = sqlite3;
import miniz;

If yes, this requires no DIP. But honestly, the reason why D requires separate import statements for renaming stuff is that it’s much clearer.

No, i specifically wrote grouped, there might be a better word for it

It means, symbols from sqlite3 and miniz are isolated into the c name

Example:

c.sqlite3_init();
c.miniz_init();

This is useful for ImportC

July 22

On Monday, 22 July 2024 at 12:29:24 UTC, Quirin Schroll wrote:

>

I just realized one can do this:

import x = std.stdio;
import x = std.file;

If that is intended, it’s especially important for clarity that separate import statements are required.

I didn't know it was possible, that's good to know, no need for that DIP then, case is closed, thanks!

July 22

On Monday, 22 July 2024 at 12:47:34 UTC, ryuukk_ wrote:

>

On Monday, 22 July 2024 at 12:29:24 UTC, Quirin Schroll wrote:

>

I just realized one can do this:

import x = std.stdio;
import x = std.file;

If that is intended, it’s especially important for clarity that separate import statements are required.

I didn't know it was possible, that's good to know, no need for that DIP then, case is closed, thanks!

I just tested, it doesn't work...

onlineapp.d(2): Error: import onlineapp.xconflicts with importonlineapp.x at onlineapp.d(1)

July 22

On Monday, 22 July 2024 at 11:23:51 UTC, ryuukk_ wrote:

>

...

I deleted some posts here and a duplicate thread.

@ryuukk_ When your DIP Idea is not understood, please clarify it in the same thread. It's the DIP author's responsibility to convey their idea to others. Do not take it out on the person giving feedback, and do not try to replace the thread with a new one.

I understand you don't want to the thread to be cluttered with initial misunderstandings, but this forum is not like git where you can easily amend and rebase if you mess up. If you want to avoid this situation, elaborate more in your initial DIP idea post with complete examples and explanations. Let's keep this thread about the DIP idea itself now, thanks!

July 23

On Monday, 22 July 2024 at 15:27:35 UTC, Dennis wrote:

>

On Monday, 22 July 2024 at 11:23:51 UTC, ryuukk_ wrote:

>

...

I deleted some posts here and a duplicate thread.

@ryuukk_ When your DIP Idea is not understood, please clarify it in the same thread. It's the DIP author's responsibility to convey their idea to others. Do not take it out on the person giving feedback, and do not try to replace the thread with a new one.

I understand you don't want to the thread to be cluttered with initial misunderstandings, but this forum is not like git where you can easily amend and rebase if you mess up. If you want to avoid this situation, elaborate more in your initial DIP idea post with complete examples and explanations. Let's keep this thread about the DIP idea itself now, thanks!

I asked for you to remove my thread, so can you please remove my thread? thanks

July 23

On Monday, 22 July 2024 at 12:49:29 UTC, ryuukk_ wrote:

>

On Monday, 22 July 2024 at 12:47:34 UTC, ryuukk_ wrote:

>

On Monday, 22 July 2024 at 12:29:24 UTC, Quirin Schroll wrote:

>

I just realized one can do this:

import x = std.stdio;
import x = std.file;

If that is intended, it’s especially important for clarity that separate import statements are required.

I didn't know it was possible, that's good to know, no need for that DIP then, case is closed, thanks!

I just tested, it doesn't work...

onlineapp.d(2): Error: import onlineapp.xconflicts with importonlineapp.x at onlineapp.d(1)

It doesn’t work for module-scope imports, as you point out, but it’s not diagnosed for function-scope imports. Filed a bug.

July 23

On Tuesday, 23 July 2024 at 10:14:18 UTC, ryuukk_ wrote:

>

I asked for you to remove my thread, so can you please remove my thread? thanks

We delete posts when they contain personal insults (both explicit and underhanded) or when they are off-topic to the point of derailing the thread. We can delete a post by special request from the author, but in the case of this thread, Quirin made replies perfectly following the DIP forum guidelines, which we won't delete without a good reason.

What I can do is informally close the thread:

From here on out, subsequent replies to this thread will be deleted.

« First   ‹ Prev
1 2