#rust-lang

so

sfackler: I wish I would have had more time for the recent allocator stuff

on the other hand, Ericson2314 talks about this stuff enough that it's among the main reasons I recognize Ericson2314's name at all

do we have compile-time/constant closures?

its been sad (at myself) that just as this has been happening

I've been busy with other projects

Soni: what are you asking? I already answered about dispatch

and less able to contribute

just as the allocator stuff finally rolled around

eddyb: not quite

what I cannot recall ever seeing is anyone else discuss the general existentials design questions

you didn't say whether const thing = a closure from hell is a valid syntax

Soni: a closure with no captures, for example, is a ZST and as such trivially constant

aaaaah

Soni: You can't have a const with an anonymous type.

s/anonymous/inferred

sfackler: the thing is, there isn't actually much design work needed

so that solves that too

Soni: when I used the const syntax I was referring to the RFC that got postponed/cancelled

ML paves the way in general

since it has a known type, getting the type is trivial

and impl trait in Rust in particular

Ericson2314: then go implement it?

yeah const closures was part of the motivation for that const type elision RFC wans't it?

Ixrec: nope

Ixrec: it's entirely unnecessary for the typical usecases

though you can coerce a const without captures to a fn pointer...

playbot: const F: fn() = || {};

Ixrec: and it makes the whole feature problematic

right, nvm

Soni: that's what I was saying by static dispatch

sfackler: I sort of tried to "go implement it" approach with https://github.com/rust-lang/rfcs/pull/1133 :/

hehe and now the momentum is there with that one again too

mbrubeck: so that has a known type

and I am the busy again

thus getting the type is automatically trivial

Soni: anyway "call aliases" is closer to a description

sfackler: like yes in an ideal world, I implement what I champion

it's still quite unlikely to become a real feature

so there's no reason why `fn foo() = X::bar(1);` would be too hard to implement

since all it does is return type elision for calling another function

but I wish there was a way to convince others that the work is easy enough that it could become a non-me priority

eddyb: with argument binding

in practice

eddyb: and optional constraints

nothing happens in any major project with core team stakeholders

Soni: yes but you get all that from writing a function *anyway*

yeah I'm still not seeing any motivation for this call aliases stuff other than "it makes the syntax similar to <language>"

Ericson2314: fwiw, i don't really agree with sfackler's "go implement it"; the problem is more that the arguments haven't been persuasive

eddyb: yeah but having to copypaste types around is a bit painful and prone to mistakes

Soni: that last part is just simply wrong

you can't put the wrong type in

Ericson2314: if you can't convince anyone else that the thing you want is interesting/easy, doesn't that indicate how many other people agree with your assessment?

it... just won't compile

eddyb: copypaste a function 50 times

then set up some bound arguments and change one of the calls to a different function

sfackler: aturon: well, mainly I've been crying a broken record in threads that switched topic

now your code doesn't compile, which is a huge annoyance

so I'm not actually sure which parts people aren't convinced by :)

Soni: you're using a language with types

why are you copypasting a function 50 times, ever?

the types are there for a reason

and the more calls you change, the more likely you'll run into that issue

I've tried to compile lists of all the other features that need it

Soni: besides, I disagree with you on macros

or you'll run into that issue multiple times

I wish macros were a bit more expressive

Ixrec: because I'm not using macros

so... use macros?

but generally, jumping into things a the moment we want to stabilize and saying "no, we must leave this for some arbitrarily long amount of time" is not reasonable

Ericson2314: the allocator design went through three very extensive RFCs, fwiw

that's literally what they're for

I could just use a macro to generate the whole function instead of just binding arguments here and there

the DSL we're working on should handle a lot of the stuff Rust can't

GLL <3

aturon: sure but that was on the traits

it was merged with boxes for some of my concerns (not this)

Ericson2314: as the clueless quasi-outsider here, I have no idea whether I agree or disagree with what you're after, since I just understand all the implications of it. Maybe I just need to see the whole thing explained from start to finish.

and that gets me the "specialized machine code" I talked about, too

those boxes were suppoed to block stabilization I thought

+don't

but then to learn my codebase you need to learn a whole completely different language

Ericson2314: hm, maybe i don't understand your concerns. What, exactly, are you worried about getting stabilized?

so now my codebase compiles like rust but doesn't read like rust at all

Soni: you can just generate the aliases with the macro...?

aturon: sure

a few things :)

some relate directly to the traits

then the lack of the general out-of-crate abstract type is orthogonal

but comes together for the "get out jemalloc" use-case

Soni: if you want to *force* instantiation for constant arguments you either use associated consts on a type parameter (on stable) or wait for RFC 2000 to be implemented

eddyb: that's not what I'm looking for

Ericson2314: i'm afraid i don't follow. can you maybe mention your #1 concern?

eddyb: I'm looking for syntax that doesn't require me to write a macro every time I wanna use it

aturon: I'm afraid there is no #1 thing

a bunch of interlocking stuff

Soni: could you talk about your actual use case maybe? I still haven't heard anything more specific than "write the same function 50 times", and I have no idea why you're saying that's an issue and not, say, writing one function and calling it 50 times.

(a few separate goals, a few features I deem necessary for those goals, and a dense relation between those features and goals)

Ixrec: they're convenience functions

Ericson2314: hm, maybe come at it a different way: if we stabilize as-is, what use-case is harmed, and why is that important?

make a fn log, then make fn info, fn warn, fn error, etc

aturon: good way to put it :)

fn info(...) { log(INFO, ...); } ?

idk about you but fn x() = y(); just reads more naturally to me than fn x() { y() }

tbh https://github.com/rust-lang/rust/issues/27389 can probably be retrofitted onto a proper parameterized crate / defered abstract type system

but

yeah, that's a completely subjective syntax choice

Soni: seriously. you have been posting on both the rfcs issues and here and being super vague about *everything*. We don't know what's in your head. We can't guess your use cases. Be clear.

and most formatters would add newlines on that thing

will hang around as weird wart

It should not take ten pages of IRC to figure out what you're talking about

and I don't have a portrait monitor

but yes if it can be retrofitted it is less bad

Ericson2314: is this primarily about being "proper"? or are there clear use-cases that are impacted?

Ixrec: say log returns a value for some reason

I'm even vaguely comfortable with Haskell-y syntax where (+1) produces a unary function, and the "fn x() = y();" stuff looks totally baffling to me

I just had no idea what any of it meant until, well, ten pages of IRC went by

and you wanna keep that value

aturon: that one is not the best, I shouldn't have led with it :), was trying to get out of the way

that one is about being proper, and a fear that politically if the use-cases are picked off one by one in and ad hoc way

there will be less momentum for general solution

also I realize the syntax I'm proposing reminds me of scala and I don't like scala

but I do like the syntax

Ericson2314: "ad hoc" and "proper" are somewhat subjective

yes

Ericson2314: FYI, i have ~2 min before i have to run...

Ericson2314: but why is a general solution important or valuable if all of the use cases of it are already subsumed by other features?

these two conversations have a lot more in common than I initially thought

aturon: ok the important thing is without associated error type in trait

Ericson2314: i agree that design by "scenario solving" is bad but i don't think that's what's happening here

Ixrec: have you ever used scala?

nope

we will never have an safe ergonomic way to write "infallible" collections

and falliable collections

oom panics will be spread out, and thus hard to maintain

rather than in 1ish general place

Soni: some of this stuff crosses into Wadler's Law territory tbh

the type of stuff gankro's RFC was hung up on

how can an allocator never fail to allocate?

are we literally debating f() = expr; vs f() { expr } syntax now?

I don't think we ever weren't debating that

sfackler: "infallible" is a bad word, but I'm in a 2 minute rush

ok so I'm proposing `fn x() = y();` as a better variant of `fn x() { y() }` in which the former compiles if y returns values while the latter doesn't

if allocation is fallible

and the collection can recover

sfackler: "infallible" means it aborts on failure https://developer.mozilla.org/en-US/docs/Infall...

eddyb: no, it's still restricted to f() = g()

i.e. failures are unrecoverable