Because in the openscad language a later module definition replaces the
earlier one without an error. Arbitrary choice of the devs like many other
features. Bosl2 actually makes use of this to extend existing modules to
make them behave consistently with certain extensions.

On Wed, Jun 10, 2026 at 10:45 Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:

What a horror.

On 6/10/2026 1:09 PM, Adrian Mariano via Discuss wrote:

I can understand method overloading, but I would hope the syntax made it
clear that it was intentional, not just a brain fart.

I cannot understand how discarding code (the original module) without a
whimper is good or useful, but I defer to Adrian that this is a feature.

Personally, I would LOVE an option to produce a warning message any time
I accidentally re-used ANY name in my code: "variable", function,
module.  In other's code, I don't care.

I imagine I will hear little support for my position.

Jon

On 6/10/2026 3:44 PM, Lee DeRaud via Discuss wrote:

Just one more rule about using OpenSCAD.  There are no laws of physics
governing how programming languages should work, and in this case the
override rule serves BOSL2.  It's what keeps me from using BOSL2 (right
now, subject to change), but that's my personal angst, no one else's.

Glenn Butcher
Former compiler design teacher.

On 6/10/2026 12:38 PM, Jon Bondy via Discuss wrote:

On 6/10/26 1:28 PM, Jon Bondy via Discuss wrote:

It was added as a quick hack to allow overwriting a variable definition
by passing in new assignment values on the command line. Unfortunately
that hacky implementation had a side effect on the semantics of the
language and make it quite unusual.

Cory

I wouldn't call it a feature exactly.  It's more like we figured out a hack
to make use of a questionable design choice in a postive, feature-like
way.

Lee compares it to method overloading, but actually it was rather tricky to
make it work.  In BOSL2 our goal is to provide some feature extensions for
consistency, so that users can still use cube() or translate() and all the
BOSL2 features work properly.  (The alternative is basically to tell BOSL2
users they should never use any of a list of 11 builtins).  We intend for
this to be transparent---you should not be able to tell that we have
replaced the built-ins.  All code that ran before should still run and
produce the same result.  In order to do that, we need to replace cube()
with a new module but still be able to call the old cube(), which requires
"using" a library that defines things like _cube() that call the original
cube().  This is messy, complex, and not obvious.  It would be much better
if there was a simple way to redefine a module while still being able to
access the previous definition.

We have taken care to make sure that cube() does the same thing as before,
but there's nothing to keep a library from being more sloppy about a
redefinition, or even nefariously redefining cube() to make cubes that are
1 unit too small, so in that respect, this is a dangerous feature, though a
cleaner redefinition feature wouldn't prevent this sort of thing.

On Wed, Jun 10, 2026 at 4:44 PM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:

[ Sigh.  I came to rely on a Thunderbird add-in that lets you set rules
for automatically selecting an appropriate address to send from, and
over the last few years TB upgrades have broken that add-in several
times.  Those typing habits are difficult to overcome. Thunderbird is
the worst mail client ever, except for all of the others. ]

On 6/10/2026 11:38 AM, Jon Bondy via Discuss wrote:

It's definitely a power tool with sharp edges and few safety features. 
I think it could have more safety features, to make it more difficult
to shoot yourself in the foot.

Adrian says:

But a cleaner feature could prevent accidentally overriding a
previously-defined module or function.  Indeed, an intentional but
poor-quality override would still be a problem.  Another concern is that
the next version of OpenSCAD might include new features for the core
module/function that conflict with the features added by the override.

Cory says:

That explains variable overriding.  It doesn't explain module/function
overriding.

Yeah, it's true that a special override feature would not be accidentally
activated.  At least the way we've done it, I don't think new features
could conflict with our override, but if they involve new parameters, the
override wouldn't support them simply because it wouldn't accept them and
pass them on to the original module, so it would cease to be transparent.
Too bad there's no way to gather all the parameters of a module and pass
them to a child module.

On Wed, Jun 10, 2026 at 9:08 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

On 6/10/26 6:07 PM, Jordan Brown via Discuss wrote:

IIRC the same implementation affected both, so all side effect.

And my problem isn't overloading per se, it's "last processed is
evaluated as if it was written at the first place the same-named thing
was written" and lack of access to preceding definitions. The
traditional shadowing has far fewer footguns.

Cory

On 6/10/2026 7:47 PM, Adrian Mariano via Discuss wrote:

Even if, say, OpenSCAD added an "anchor" parameter to cube()?

The editor? flags if a module does not exist, so it 'knows' what modules
are present. It should be relatively easy to flag duplicate modules, it
could print a warning message in the console, not necessarily treating
as an error. It may need treating slightly differently than duplicate
variable names, if 'stopping on first warning'

On 11/06/2026 04:29, Jordan Brown via Discuss wrote:

Yeah, if OpenSCAD added "anchor" to cube() that would indeed conflict with
the override, but really that would be a much bigger problem than just the
override, since it would create a bunch of confusion between the native
feature and the BOSL2 feature.  We'd probably have to redesign the library
API in some significant way.

On Wed, Jun 10, 2026 at 11:29 PM Jordan Brown openscad@jordan.maileater.net
wrote:

Does the editor know what modules are in the included (e.g. BOSL2) files? Or
even in the current active file, for that matter.
Seems like a fair bit of functionality from the parser/interpreter would
have be duplicated in the editor.

-----Original Message-----
From: Raymond West via Discuss discuss@lists.openscad.org
Sent: Thursday, June 11, 2026 4:27 AM
To: Jordan Brown via Discuss discuss@lists.openscad.org
Cc: Raymond West raywest@raywest.com
Subject: [OpenSCAD] Re: redefining a module()

The editor? flags if a module does not exist, so it 'knows' what modules are
present. It should be relatively easy to flag duplicate modules, it could
print a warning message in the console, not necessarily treating as an
error. It may need treating slightly differently than duplicate variable
names, if 'stopping on first warning'

On 11/06/2026 04:29, Jordan Brown via Discuss wrote:

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

On 6/11/2026 5:02 AM, Adrian Mariano wrote:

Right, that's the potential problem with this style, where a library
overrides a builtin to add features.  Any one case has a low probability
of ever being a problem, but if people do it more and more, eventually
there will be a problem.

For instance, it would be easy for a library to "address" a longstanding
request that the "center" parameter accept other variations, to position
the shape to the positive, center, or negative side of each axis.  But
then if OpenSCAD itself ever addressed that request, and didn't do it in
exactly the same way as the library, it would be ... bad.

This kind of override is really really cool when there doesn't end up
being a collision, for exactly the reason that you did it:  it yields a
seamless API.  But if there ever is a collision, there will be pain.

No, it's more fundamental than that.  If OpenSCAD adds some kind of anchor
feature then we have a basic conceptual conflict between what anchor means
in native OpenScad and what it means in BOSL2.  It transcends the override
issue.  Without the override you'd have a situation where
cuboid(....anchor=) does one thing and cube(...anchor=...) does another
thing.  This is fundamentally confusing and much worse than
cuboid(anchor=...) does something and cube(anchor=...) is an error.  The
only fix for this would be for BOSL2 to refactor its API and stop using
anchor= as a parameter throughout the entire library.  And we'd have to
consider this change even if we had never done any overrides.  The risk is
not created by the override.  It's a risk the risk of adding any broad
functionality in a library: OpenSCAD could change in a way that conflicts
with it.

Doing the overrides does not increase our exposure to that risk.

On Thu, Jun 11, 2026 at 11:12 AM Jordan Brown openscad@jordan.maileater.net
wrote:

On 6/11/2026 10:42 AM, Adrian Mariano wrote:

Eh, sort of.  Yes, when a library introduces a "broad" feature, a
behavior that it presents as ubiquitous, and OpenSCAD evolves to have a
similar-but-different feature, that's a conflict of sorts, a
disharmony.  However, one can still draw a line around the OpenSCAD
components and the library components, and say that different rules
apply to each.

And in fact you do that:  OpenSCAD constructs extend into +Z by default
(and +XY for cube and square), while BOSL2 constructs are centered by
default.  OpenSCAD cube() and BOSL2 cuboid(), and OpenSCAD cylinder()
and BOSL2 cyl(), do very similar things but have different origin points.

But drawing that kind of line isn't possible when the library has
augmented the builtins, because those augmented builtins are then inside
both circles, and they might (in the future) conflict.

To be clear:  I'm not saying that BOSL2's overrides of the builtins are
wrong.  There's a tradeoff:  cleaner overall API, versus future
compatibility risk.  There are arguments on both sides.  Personally, I
probably wouldn't have done it, because you already felt the need for
cuboid() and cyl(); once you are saying "here's the better way" it's not
much of a leap to "we recommend not using the old way".  You chose
differently, and that's OK.

On 6/11/26 11:03 AM, Jordan Brown via Discuss wrote:

That is not true:

https://github.com/BelfrySCAD/BOSL2/wiki/shapes3d.scad#functionmodule-cube

IIRC you should not be able to create a basic shape in raw OpenSCAD with
all valid inputs, then import BOSL2 and have it work differently; I'm
fairly certain that would be considered a bug unless there's a
documented good reason otherwise.

Cory

On 6/11/26 11:09 AM, Cory Cross via Discuss wrote:

Oh, I see now, you aren't counting BOSL2's cube, only cuboid. I
guess I don't have anything to add.

On 6/11/26 11:37 AM, Lee DeRaud via Discuss wrote:

The rate of enhancement in the base OpenSCAD library has slowed to a
crawl, so it's unlikely to happen. The basic argument seems to be "if
you can do it somehow without changing the builtins, then that's how you
should do it".

The focus has been on speed/performance improvements (Manifold), things
which make libraries easier to write (i.e. Objects), UI, and I/O (i.e.
exporting better to 3mf). The maintainers have decided no breaking
changes (even to "incorrect" code) shall be made without a high bar. And
so if center="right" made things centered, you can't make that now put
the origin at the left side of the cube, because someone could have a
model that now works differently.

But there is some freedom in that: you can use BOSL2 and a given version
of BOSL2 will be extremely unlikely to work differently on different
versions of OpenSCAD.

But it's really unfortunate the version of OpenSCAD you get from the
website is 1. so outdated and 2. doesn't include BOSL2, but there's
already discussions on those points.

Cory

On 6/11/2026 11:37 AM, Lee DeRaud via Discuss wrote:

If you stay away from overriding, the major place that can happen is in
module/function names.  Has there ever been a library that started using
some name X, and then later OpenSCAD started using that same name?  No
idea.  Or, similarly, a conflict between a main program and a library,
or a main program and OpenSCAD?  (That possibility is one of the things
that I'd like to fix in a hypothetical future replacement for "use".) 
OpenSCAD evolves very slowly in that area, so there are very few
opportunities for conflict - and, mostly, since the library
implementation will "win", there will only be a conflict if somebody's
trying to use the new built-in feature.

Any library sets its own standard, so that's already happened.  The
question that I think you're asking is whether there's a point at which
OpenSCAD would change its course, away from the course we might
otherwise select, to align with some library or to avoid a conflict with
some library.  I think that will always be handled on a case-by-case basis.

There are two levels of "base" functionality.

You can have stuff that's built into the program itself and implemented
in C++, like cube(), that you get without any "include <>" or "use <>". 
There's been a pretty conscious decision to minimize those things,
adding them only when they simply can't be implemented in
OpenSCAD-language, or when there's a major performance difference
between a C++ implementation and an OpenSCAD-language implementation. 
There are two reasons for that decision:  (1) writing C++ is harder and
riskier than writing OpenSCAD-language, and (2) once it's in the C++,
it's very difficult to change it or take it out with making somebody
unhappy.  If it's in OpenSCAD-language, and you get to it using "include
<BOSL2.scad/std.scad>", tomorrow you can introduce BOSL3 and consumers
can "include <BOSL3/std.scad>", without causing any problems for
BOSL2-based programs.  We have lots of stuff today that's implemented in
C++ that could be implemented in OpenSCAD-language; if we were starting
with a blank slate I wouldn't be surprised if the list of builtin
modules and functions was much smaller, with the remainder supplied by a
bundled library.

There can be libraries that are bundled with OpenSCAD, that are
installed by default.  You access them with "include <>" or "use <>",
just as for an unbundled library.  MCAD is bundled with OpenSCAD.  BOSL2
could be bundled with OpenSCAD.  Why isn't it?  Because the BOSL2
authors have decided they don't want it to be.  (I don't think the
question has come up yet whether OpenSCAD would accept it.)  Why don't
they want it to be?  I haven't talked to them deeply about it, but I
think the answers are roughly wanting to be the masters of their own
destiny, and not wanting to be bound up with the OpenSCAD release schedule.

I think the high-level and never-quite-accomplished goal is for OpenSCAD
to get a package manager, so that installing a library is just a matter
of selecting it and saying "install", rather than needing to pick which
libraries to bundle.

BOSL2 is extremely important to how I code in OpenSCAD.  Were OpenSCAD
to create a release that made it incompatible with BOSL2, or screwed up
BOSL2 for no universally agreed reason, I would question the wisdom of
the changes in that release.  It may not be a question of the tail
wagging the dog, but perhaps the shoulders wagging the hips.  I see the
two as inexorably bound together, already.

Jon

On 6/11/2026 2:37 PM, Lee DeRaud via Discuss wrote:

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

We have never had any conversation with the OpenSCAD devs about how the
BOSL2 feature set interacts with the "base" functionality.  The devs do,
however, have a general mindset that if you can do it in userspace they
should not add it to core OpenSCAD.  This appears to apply even when the
OpenSCAD implementation is fragile, difficult, and orders of magnitude
slower.  I'll also note that OpenSCAD seems to have had its first release
in 2010 and BOSL2 development looks like it commenced sometime around 2018,
so OpenSCAD development was well underway when BOSL2 got its start.

River tried to get polygon operations (the clipper library) exposed as user
functions, for example, with a working PR.  The implementation he wrote in
userspace is probably 1000x slower at least than the native version.  But
that didn't fly.  Another questionable situation: I implemented solutions
to linear systems of equations in OpenSCAD.  In recent tests I realized my
code was 100,000 times slower than native code would be (e.g. by comparing
to Octave).  Rock solid and highly optimized implementations of linear
algebra exist in packages like eigen or lapack, so why am I wasting my time
trying to figure out why my code is 10^5 times slower than the reference?
I did discover a way to rewrite the code to make it faster---it involved
doing all the operations on transposed matrices, basically doing everything
turned sideways from how all the algorithms appear in the textbooks.  I've
forgotten the exact timings but I think it's now "only" 100-1000 times
slower than native.  I don't generally see much point in trying to get
stuff like this added to core OpenSCAD because it doesn't seem to actually
happen.

Jordan, yes, you can draw a line around OpenSCAD and the library and say
that different rules apply.  The problem is, the users will be confused and
won't get it, and we'll get a ton of bug reports.  This gets back to the
reason for the overrides, which is that it avoids us having a list of
"these 11 modules you must never use".  It's not all the core modules,
just some of them.  And it actually changed when I added descriptions and
had to override translate, rotate and multmatrix.  So if OpenSCAD added a
core anchor feature that conflicted with the BOSL2 anchor feature we'd be
in that situation but it would probably be even more confusing when users
mistakenly used the forbidden modules.  So while yes, technically BOSL2
could coexist with this imagined new feature, in practice it would probably
result in the rise of BOSL3 with a different API to reduce confusion.

Another observation is that sure, you can say "only use the BOSL2 functions
in BOSL2" but what if you need to use other code from some other non-BOSL2
source?  You have to translate it to BOSL2 before you can use it?

Cory said, "The rate of enhancement in the base OpenSCAD library has slowed
to a crawl".  That's an interesting perspective.  I'd say it's always been
at a crawl--or slower.  When I first started using OpenSCAD the situation
was much the same: the "stable" version was years old and missing useful
features I found I needed.  And this connects to the issue of BOSL2 being
bundled with OpenSCAD.  Would you want to be stuck with the 2021 version of
BOSL2?  I'll admit that if OpenSCAD errs on the side of excessive
stability,  BOSL2 errs in the other direction---tying releases to an every
5+ years schedule definitely doesn't suit us.

On Thu, Jun 11, 2026 at 2:37 PM Lee DeRaud via Discuss <
discuss@lists.openscad.org> wrote:

Not really… OpenSCAD changes so glacially that it never really happens in practice.  It took three years for object() to be added, and the module literals it was supposed to come with still haven’t appeared. I HAVE tried suggesting ways to fix the broken use<> in a way that would provide namespaces, though.

lib = use<lib.scad>;
foo = lib.func(blah);

On the other hand, OpenSCAD DID change the rules for allowed function and module names to exclude starting with numbers, so that numbers in 0xDEADBEEF hex notation could be added. That messed badly with nopSCADlib, as I recall, since it had modules named for various electrical parts whose names started with numbers.

I admit that starting module names with numbers is kinda sketchy. But so is taking advantage of having separate namespaces for modules, functions, and variables. I ended up leaning heavily on that myself, so I can’t blame nophead much. What isn’t forbidden is allowed.

-Revar

I wouldn’t mind if OpenSCAD shipped with snapshots of BOSL2, but I’m not tying BOSL2’s development schedule to it.

-Revar

If OpenSCAD shipped with BOSL2 snapshots then this would make whatever
BOSL2 release shipped with the "stable" OpenSCAD into the de facto official
BOSL2 release.

On Thu, Jun 11, 2026 at 8:41 PM Revar Desmera via Discuss <
discuss@lists.openscad.org> wrote:

"What isn’t forbidden is allowed."

What isn't forbidden becomes commonplace?

:)

On 6/11/2026 8:36 PM, Revar Desmera via Discuss wrote:

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

So, BOSL5 then.

-Revar