Renaming @mixin?

There are more suggestions than people discussing, and so far no suggestion has found any substantial support. So, I have decided to go ahead with transparent. transparent actually fits quite well with how we use the term currently. For inline methods, transparent means that the result type of the method does not figure in the expanded term. Conversely, an opaque alias means that the defined type does show up as its own entity, it is not just expanded away. By that terminology, normal type aliases are also transparent. So, transparent means that a type is somehow invisible or immaterial. The new meaning of transparent is analogous: A transparent trait does not show up in lubs, and, since the idea is that transparent traits are only used as mixins but not as types of values, would therefore not show up in any inferred type.

So I think it fits quite well, and we don’t need to invent a new modifier or annotation for it.


I am convinced by the logic. transparent is a good choice. I support it!

(It’s really more translucent because it’s not completely invisible or immaterial.)


“Transparent” means you can see through it, but it doesn’t mean you can’t see the thing itself.

Like that water bottle next to me. The bottle is transparent, and so is the water, but I can still see both of them.

If I understand correctly, in the case of transparent inline methods, it just means the typechecker can see what is inside.

Is there anything you can see in a “transparent” trait that you cannot already see in a regular trait?

And the whole purpose is to suppress inferring with Product with Serializable for case class unions, isn’t it?

At some point the analogy breaks down. You can see transparent objects mostly because of the change of index of refraction. You can’t see transparent index-matched plastic inside water.

What is transparent here is the type of the trait. You still have the trait, you can still see the type explicitly, but it gets overlooked during type inference (so the inferred type is wider than it would be, overlooking the transparent trait).

Seems like a good enough analogy to me.

1 Like

Wouldn’t transparent indicate that there’s some sort of a relationship between this feature and opaque types?



What I mean is that opaque types and mixin traits are not opposites, and renaming “mixin” to “transparent” will cause confusion. From Opaque data type in Wikipedia:

In computer science an opaque data type is a data type whose concrete data structure is not defined in an interface. This enforces information hiding, since its values can only be manipulated by calling subroutines that have access to the missing information. The concrete representation of the type is hidden from its users, and the visible implementation is incomplete. A data type whose representation is visible is called transparent.

I don’t see how mixin traits fall under the definition of “transparent” in the context of opaque types.

Most of programmers probably know transparent from CSS colors and similar stuff. So the “level of transparency” can change though. :stuck_out_tongue:
And because not all of us are english native speakers, let’s not take dictionaries and dig through it. It’s good enough.

I’m not a native speaker either, and the first place I’ll go to when I see a word I’m not familiar with (say, opaque) would be a dictionary or encyclopedia.

I would then assume a clear relationship between opaque-transparent keywords/standard library terms, just as I would expect it from private-public, long-short, some-none, etc.

I’m actually in favor of @impl/entation, as it denotes that said trait is not a “descriptive”/“interface” trait, but is intended to be used for inheriting functionality, which would raise the question of whether this functionality should be inherited or composed (at least for those concerned with composition over inheritance).

“lubexclude” seems like a clear winner to me. Intermediate and advanced Scala programmers will understand the name and beginners will be encouraged to learn what LUB stands for, which is necessary to go beyond basic use of the language.

Where as I would find the meaning of “transparent” opaque. :smile:


Whereas I agree with some of the above comments saying transparent is confusing, will transparent traits really be used often enough for that to become a problem? There’s a handful of traits in the standard library, and perhaps a few in other libraries, but I doubt these will ever be a common thing.

I would suggest that one of the principles of naming should be that misleading names should be avoided. It is better to use a name that conveys no meaning rather than one that is misleading. With commonly used terms, a new term name can often be desirable. I would suggest for example that it would be a really good idea for us to make up a word for “type class”. Rarely used terms should be meaningful and can be made long if necessary.

@impl, @implementation make the most sense to me, but I guess @transparent could work as well.