#rust-lang

re: the whole debate about impl Trait aliases maybe being confusing by not unifying

apparently in the C++ concepts TS if you write "Number add(Number a, Number b, Number... rest) { ... }" then those first three Numbers have to be the same type but all the varargs Numbers at the end can all be different types

we could be so much worse lol

its C++ what else would you expect

I have slightly higher expectations of modern C++

(though apparently there's a proposal to fix this)

modern c++ is what brought us prvalues and friends

not C++03

I gotta go relearn what an xvalue is

what are impl trait aliases

it would be nice to have a shorthand for writing a long `impl Trait<...>` a bunch of times

but it is also nice to be able to name a single `impl Trait`

est31: the `type Foo = impl Trait;` syntax as proposed in https://github.com/rust-lang/rfcs/pull/2071

err why do you need that??

Ralith: I accidentally proposed "trait aliases" in that RFC thread I just linked for exactly that purpose

isnt it the point of impl trait to get rid of naming

and was then told that we already have an accepted RFC for trait aliases

which

though of course it's an old RFC so it doesn't mention impl Trait but I assume it'd work with it if we ever implemented it

est31: for me, the most important part is to support naming unnameable things

it is a couple different features in one

again, isnt the point of impl trait that you can *avoid* naming things

I mean if you want to name them, just use generic type parameters

that's one of the points

but they're also shorthand for generic type parameters

in the simple case

fcp merge... oh common

and with type Foo = impl Trait it becomes a syntax for...I guess giving an abstract name to a type without giving away the concrete name of that type

est31: you can't use generic type parameters if it's not generic

they are changing the language in a super fast pace

half the discussion there is about whether we've given it too many meanings

rust is definitely not a stable language

its a joke that rust is stable lol

"stability without stagnation"

I mean if "stable" means not adding features then the only stable languages are the dead ones these days

a language that doesnt pile on garbage each year getting more and more complicated is not a dead language

its one which you can actually learn

like C

C is not dead

its used by millions of coders

or haskell

C also added some features not too long ago

haskell isn't dead either

and you can add non-garbage features

haskell as used in practice piles on features like nobody's business

I've never used "haskell in practice", but I hear the feature flag situation is such that you basically change the feature set every time you switch projects? is that true?

I don't think impl Trait is garbage

its not garbage

but the pace is definitely too fast

proper impl trait isnt even arrived on stable

I couldnt actually get experience with it

and impl trait already has deep issues

like hiding api boundaries

because of specialisation

For me, impl Trait is a feature that is solely there for iterators

Ixrec: Haskell projects declare their feature flags in source/cabal files, and they tend to vary, yeah

impl trait is far too close to C++'s auto for me

it should be used in as little places as possible

what's the issue with auto that it shares?

usable in return position

hmm

I'm not against the RFC

still, this stuff is happening too fast for me

I thought return position was like the entire core motivation

I can understand the too fast thing though. I don't feel that way, but I have no counterargument.

Ixrec: I want type info to be fixed at the function boundary

but it is?

not with impl trait

you change your implementation, the returned type may change

if it still impls the trait, no problem

are you talking about the auto trait leakage or the captured parameters things?

buuut it might exhibit different behaviour

isn't one of the other points of the features to make changing the implementation type backwards compatible?

because of specialisation

I mean, you can change code to give it different behavior without specialization

thats not the point

Ixrec: to get this correctly, type Adder = impl Fn(usize) -> usize;

this means that Adder is now a "macro" for impl Trait

and basically it can be different types

but what if you have type Item = impl Debug; in that impl Iterator for MyType {

then Item must be one fixed type, doesnt it?

I thought an alias like that would always refer to a single type

hmm

it seems the RFC says what you say Ralith

its all one type "in reality"

idk

I've attempted to find things about the proposal to be -1 about

but didnt find one

but I'm no fan of it.

also it adds to my belief that ergonomics and learnability are at odds to each other

because as ergonomic as this feature may seem, it adds to the learning curve

at least my experience with most RFCs

of that initiative

I just dont want Rust to become another C++ ... a monster of thousands of features which you all dont understand

I rather have it be another C, simple and mostly not hard to understand

even if you might have to type a little bit more in some cases

but I guess its walking more into the "as hard to learn as C++" than the "diamond of simple beauty" direction

Ixrec: why are you supportive of it?

what use cases does it enable for you?

hmm gtg