#rust-lang

yes

there are less ideal solutions which are better than the current solution

for example, mtgs which are open to all, but only a few talk

or even just bloody notes

I wonder how many people would show up if they could

I and WindowsBunnyGhostBusters

trying to manage a meeting with a dozen people wanting to talk kinda sucks

are the two who really want to show up

I don't doubt there are others also

we're the ones who are complaining about the closed meeting :P

heh

fair

jntrnr: C++ does pretty fine with large meetings

WindowsBunnyGhostBusters: they've developed a lot of structure to support it

jntrnr: that's not a good excuse

not an excuse :-/

just sayin'

jntrnr: Since Rust definitely doesn't have a shortage of accepted RFCs that need implementing, I'd say a committee process would be great

it would slow down the RFC process for sure

I *am* glad the committees we do have don't cost money to be part of

unlike ECMAScript and C++

well the meetings are open to everyone, you just have to pay to be a member which gives you more voting rights

jntrnr: the C++ committees don't cost money to be a part of

they're volunteer

>Meetings are open to the public, and we welcome people to attend for a meeting or two as an observer; this lets you participate and argue and do most everything, except only you can’t actually participate in change approval polls.

and technically, nobody gets a vote except for the teams

in Rust

which means, mozilla gets all the votes :)

so if we just had open meetings over the internet where only the teams got to vote, but anyone could participate, we'd be on par with C++

and then it would just be a matter of scaling it up

except that everybody on the lang team seems to be paid by the same company...

well, 'cept for huonw

so, everybody but 1

no other company has any power

... yayyyy...

ubsan: I wonder if we opened it up so anyone could pay to be part of the team, would anyone take up that offer?

I doubt it would work

at least until we get something like https://isocpp.org/

I'd like to see other companies have more power if in combination they also contribute in important ways

scott: right

ubsan: sure, though Rust is like a year old?

not that the concerns aren't valid

just things take time to mature generally

C++ took a while to get there (years) and for C# etc

jntrnr: that's true

this is more complaining based on being locked out

yeah

Gankro: yes, we've emailed Duffy

👍

C++ has generic closures, right? https://github.com/rust-lang/rfcs/pull/1650#iss...

does it allow passing a templated function around with the template unapplied?

or maybe it has to be a templated operator() of a monomorphic class

eddyb: templated function around with the template unapplied?

like

fn<T>(T)?

I imagine so

ubsan: like given template<typename T> T foo() { return T(); }, passing foo around

not as a function pointer but as a callable

I don't think C++ lets you do this, but I'm not sure

you need SFINAE

and HKT

so

with closures it works because this works:

struct foo { template<typename T> T operator() { return T(); } } and then passing foo{} around

although, *that* definition might be wrong

it should work fine with generic arguments

template <template<typename> class F> int foo(F f) { static_if(std::is_callable<F<int>, int>::value, "Must be callable with no args returning int"); return F<int>(0); }

eddyb: ^

oh wait

ubsan: no, that's not really what I mean

template <template<typename> class F> int foo(F f) { static_if(std::is_callable<F<int>, int, int>::value, "Must be callable with one arg (int) returning int"); return F<int>(0); }

eddyb: SFINAE is C++'s bounds

ubsan: I mean template<typename F> which can then be used as a generic closure

huh?

no

it has to be higher kinded, I think

ubsan: C++ has generic closures anyway

without higher kindedness

I just don't think you can use templated functions like that

.clang { cout << foo(doop); } template <typename T> T doop(T t) { return t; } template <template<typename> class F> int foo(F f) { static_if(std::is_callable<F<int>, int, int>::value, "Must be callable with one arg (int) returning int"); return F<int>(0); }

Is it really worth it though? To cover a simple edgecase, when it can effectively be solved by higher kinded polymorphism.

ticki: they're not the same thing

Well, they are.

You can parameterize closures over type lambdas.

ticki: functions are not higher-kinded, they're higher-ranked

Then the application infers these and performs η-reduction.

*generic functions

eddyb: type lambdas, not lambdas.

ticki: how is that relevant to the discussion

Well, say some closure is parameterized over some arbitrary type, that's generics.

(or rather, generic functions can have parameters which add to their kind - early-bound - or parameters which add to their rank - late-bound)

HKP allows for such a parameterization.

ticki: for lifetimes, we couldn't force that, it would've broken stuff

or rather, it would've made e.g. fn(&T) impossible to obtain

Yeah, lifetimes are sort of weird in this case, especially due to subtyping relations.

should they be special though?

yeah?

I think they should be

ubsan: so you're against generic closures?

eddyb: no

If you want full expressiveness, yes.

because generic closures are higher-ranked, not higher-kinded

I just think that lifetimes are special

for<'a> is basically a type-lambda constraint to a region.

AFAICT, ticki is saying that higher-ranked for types is unnecessary because you can do higher-kinded

Well, not really.

but higher-kinded is annoying to work with

My point is that one falls from the other.

well, higher-ranked for types is impossible because different types can make codegen different

eddyb: How so? Type inference makes stuff relatively easy.

it's necessary in some cases, but not most of the usual ones

as I understand it

ubsan: No, it shouldn't affect codegen.

ubsan: not on function pointers, but on generic bounds

ticki: it should though

Oh, well. The type constructors, you mean?

fn(T), depending on T, should result in different code

Because those affects codegen. I get your point.

Yeah

whereas fn(&'a T), depending on 'a, does not

typeof Clone::clone: for<T: Clone> Fn(&T) -> T

still confused on why early-late matters unless one turns the closure to a trait object

Ericson2314: that's not what early-late is about

eddyb: I guess typeck would go something like:

Ericson2314: early-late is kind-rank

Ericson2314: HRTB, not for<...> Trait or for<...> fn()

Figure the rhs to be λx: Clone.&T → T.

i realize

Ericson2314: you cannot use HRTB with early-bound parameters

ticki: did you mean to use &x -> x?

that would be a restriction on the *consumer* of the closure, no?

Yeah

or are we no longer talking about generic closure creation?

We are.

imma ready eddyb's post again then

eddyb: not sure if this was clarified earlier: I believe C++17 has generic closures (with `auto` argument types) - but they are, as far as I know, restricted to local scopes so you don't get into higher-ranked situations

I'd be interested to see if I'm wrong about the latter

eddyb looking at your comment, there are no additional restrictions from writing out the closure as a struct by hand?

but may be worthwhile to remove the "no impl<T> Fn() for X" for manual impls and closures?