proposal: Allow importing functions, types, or variables from a module without importing the entire module

[arjendevos]

Importing is a common feature, and especially import in this project as every file is a module. That is why I am proposing partial imports, so you can import only what you need from a module without importing the entire module.

Current way

import math // imports the entire module
import math as m // aliasing the module
import math as * // import everything directly

Proposals

// Proposal 1:
import math { sqrt, pow } // importing specific functions
import math { sqrt as square_root, pow as power } // importing with aliasing

import math fn { sqrt, pow }
import math type { SomeType } 
import math const { Pi } 
import math var { some_variable } 

// Proposal 2:
import { sqrt, pow } from math // importing specific functions
import { sqrt as square_root, pow as power } from math // importing with aliasing

import fn { sqrt, pow } from math
import type { SomeType } from math
import const { Pi } from math
import var { some_variable } from math

// Proposal 3
import math use { sqrt, pow } // importing specific functions
import math use { sqrt as square_root, pow as power } // importing with aliasing

import math use fn { sqrt, pow }
import math use type { SomeType } 
import math use const { Pi } 
import math use var { some_variable }

Reasoning

Personally I'm the most fan of proposal 3 as that keeps the current import syntax and adds the use keyword, like the as keyword for aliasing.

Proposal 1 feels a bit weird to use and proposal 2 changes the entire import syntax which I don't think is necessary.

I'm personally also not a fan of declaring the type of import (fn, type, const, var) as that adds more complexity to the syntax and I don't see a big benefit of it unless there are performance implications, which I don't think there are.

The as * kinda solves it already but it also causes conflicting issues. In go this isn't recommended and I think we should adhere to that. Just importing a single function that is unique (like UserController) is very much needed. Something I always hated in go, when developing api's, was the package names. For example I had multiple user namespaces (controllers/requests/models), which would conflict when importing into a single file.

ISSUE: when importing with as * duplicates are not catched by the compiler.

Examples in other languages

Go:

import "math"
import m "math" // aliasing

Rust:

use std::f64; // importing the entire module
use std::f64::consts::PI; // importing specific constant
use std::cmp::{min, max}; // importing specific functions

Swift:

import Foundation // importing the entire module
import func Darwin.min // importing specific function
import func Darwin.max // importing specific function

Kotlin:

import kotlin.math.sqrt
import kotlin.math.pow
import kotlin.math.PI
import kotlin.math.min
import kotlin.math.max

Python:

import math # importing the entire module
from math import sqrt, pow, pi, inf # importing specific functions and constants
from math import min as math_min, max as math_max # importing specific functions with aliasing

JavaScript/TypeScript:

import * as math from 'mathjs'; // importing the entire module
import { sqrt, pow, pi, min, max } from 'mathjs'; // importing specific functions and constants
import type { MathJsStatic } from 'mathjs'; // importing specific types (typescript)

Conclusion

Would love to hear your thoughts on this proposal and if there are any downsides to it.

[weiwenhao]

I considered this syntax, but it's not a syntax that would affect core development, so I didn't push it further. I just think that the use of quque_t in situations like the following is very redundant, so I'm inclined to add the relevant syntax.

import queue

fn main() {
	var q = queue.queue_t{
		// ...
	}
}

Based on your proposal, I think the following three proposals are worth considering: 1. Conciseness; 3. Readability.

// origin
import foo.bar
import foo.bar as b
import foo.bar as *

// Proposal 1
import coroutines {mutex, yield, sleep as co_sleep}
import coroutines {mutex}

// Proposal 2
import coroutines.{mutex, yield, sleep as co_sleep}
import coroutines.{mutex}

// Proposal 3
import coroutines use {mutex, yield, sleep as co_sleep}
import coroutines use {mutex}

However, I prefer Proposal 2, which is readable without introducing extra keywords. It also stipulates that when importing members from a module, {} must be declared, even if only a single member is imported. This allows for quick differentiation between importing a module and importing members from the same module. Furthermore, it allows importing a module while simultaneously importing members from the same module. Of course, I'm not sure if this syntax has any ambiguity or other issues.

import foo.bar as fb

import foo.bar.{m1, m2, m3 as ma}

As an additional point, this syntax extends fn extend, adding more uncertainty (neither Go nor Kotlin supports this). This feature is currently reserved but will not appear in the official documentation.

imoprt quque.{queue_t}

fn queue_t.to_string():string {
	// ...
}

[arjendevos]

I agree with your proposal (2). It makes sense as we already use dot for importing modules.

As for the fn extend: I personally would love to be able to extend imported types but I think we want to mark the type as something first to make very clear that this is an extended type. However I'm not entirely sure how this would work, seems quite complicate?

[weiwenhao]

I agree with your proposal (2). It makes sense as we already use dot for importing modules.
As for the fn extend: I personally would love to be able to extend imported types but I think we want to mark the type as something first to make very clear that this is an extended type. However I'm not entirely sure how this would work, seems quite complicate?

fn extend is merely an additional suggestion and does not affect the functional development of this proposal.

fn extend will remain unchanged for now. Given its close association with impl, the need for additional support can be further considered in other issues.

[arjendevos]

Will work on a pr this week. I'm closing the proof of concept.