# Wildcards - problems and investigated solutions

Problem: If I have multiple wildcards in my code, I can get a name clash.

Wildcards in user code are not a problem. If I get a name clash, I can immediately fix it.

But it starts being a challenge in library code. Library authors generally expect that adding a function is not a breaking change. However, wildcard imports can cause it to be an unintended breaking change.

This becomes a problem for libraries which in turn depend on othre libraries.
For example, if I depend on "cool-utils", which internally does

import bevy::prelude::*;
import lygia::math::*;

then a *patch* version upgrade of lygia can cause the code to stop compiling. It is a bad user experience when a patch version change of an *indirect* dependency causes breakage. This goes against our goal of having a good and successful library ecosystem.

The same scenario can be constructed with builtin functions:
Library A wildcard imports from library B.
Library B adds a function which happens to shadow a builtin.
Library A is now using the wrong function.

## Attempt - Disallow wildcards

We could just outright disallow wildcards. Many programming languages have done so, such as Javascript and many more warn against using wildcards.

However, that would not satisfy Bevy's use case. So we need to look for better.

## Attempt - Item-level opt-in wildcards

The Julia programming language distinguishes between "can be explicitly imported" (`public`) and "can be wildcard imported" (`export`).

However, that comes with the catch of a wildcard import potentially not importing everything. This behaviour seems surprising, especially since it is not commonly seen in other programming languages.

// does not import everything
import my_lib::*;

// instead if I wanted everything, I would have to spell out the missing items
import my_lib::{*, foo, bar, alsothis};

## Attempt - Module level opt-in wildcards

Ideally, the publisher should control what modules they promise to be safe for wildcard importing. If the publisher adds a function to those modules, they promise to properly bump the semver version.

However, we struggled to find a good and obvious syntax for this. Adding new syntax comes at a high cost.

## Proposal - Diagnostics for module level opt-in wildcards

We can make use of WGSL diagnostics and warn against unsafe usages [diagnostics](https://www.w3.org/TR/WGSL/#diagnostic-filtering)
It would be a deny-by-default diagnostic that compliant WESL implementations check for.

In a library, we would see code like

@diagnostic(off, wildcard_import) // implied, since the name is "prelude". Written out for clarity in this example
export package::color::prelude;

and on the consumer side, we would see code like

import bevy::color::prelude::*; // allowed by the library

import package::utils::*; // allowed, same package

@diagnostic(off, wildcard_import) // would be rejected otherwise. This is the consumer opting into the "may break on patch version upgrades" behaviour
import lygia::math::*; 

## Proposal - Rewrite upon publishing

When I publish a library, I know what each wildcard expands to.

So wesl could rewrite each wildcard into an explicit list upon publishing. Thus avoiding the issue.

The side-effect of this is that re-exporting a wildcard will be expanded to a fixed list. As in

pub import bevy::prelude::*;

will expand to

pub import bevy::prelude::{foo, bar, baz};

Even if the Bevy dependency changes, the re-export will not. This behaviour could be seen either as unexpected or as desirable.