Change module/package loading to include the extension

[Summertime]

(for at least project-local files)

being able to do the following

var otherfile = (import "./otherfile.ö");

would simplify package resolution, be easier to teach and learn (doesn't require understanding two distinct views of the filesystem), and would allow more complex situations to be easier to manage (pre-processing resulting in multiple "views" of the same code, in different files, as an example)

[Akuli]

If I have a lol.ö library and I want to add more files, I need to break backwards compatibility by forcing people to import "lol/somefile.ö".

[Summertime]

sidebar:

I think a question to answer before that is how would importing a directory work?

x.odotdot
lol/
  |-- <somename>.odotdot
  |-- file1.odotdot
  |-- file2.odotdot
  `-- file3.odotdot

I want to import all of lol

should <somename>.odotdot be __init__.odotdot or _.odotdot or even just .odotdot

to import, "./lol", "./lol/", "./lol/<somename>.odotdot", or something else?

[Summertime]

I think the backwards compatibility story can be solved by the package maintainer having a stub lol.ö that points to lol/somefile.ö

in that case its just the same as maintaining any API, keep things in the old places which wrap the new underlying code

[Akuli]

<somename>: could be probably something like exports

stub files: might be confusing, i like your point about how it doesn't differ much from other api maintaining, maybe it's a good idea after all

which import string: i had thought of (import "./lol"), where the ./ is optional because it always imports relative to current file unless the import starts with <std>

[Akuli]

1 more reason why having .ö at the end of the import would be good:

$ grep -r shit.ö   # where is this garbage used?