requiring positional args to use the assignment syntax
Not sure, maybe my wording isn't clear enough.
What I intended to say is that arguments can be named, not that they have to.
In any case, the order of arguments must match the order of parameters, named or not.
But you’re also missing one use of the impl keyword: fn func() -> impl Trait.
That removal could actually happen, so I didn't list it. (Rust started requiring dyn and disallowed naked trait returns with edition 2018. So dropping the impl in that position might not be completely impossible like the other uses of impl.)
Are you suggesting using keywords/methods [for array and slice syntax] instead?
Yes, just methods.
I can understand someone preferring the PartialEq/PartialOrd behavior
You can have both – that's what's being made possible by them not being in a hierarchy.
I think if-let makes sense, but don’t expand it.
It's a bit late for that, isn't it? ;-)
Why? What value does -> () provide? Why not elide that?
What value is provided by keeping it? Why a syntactic special-case for exactly that type and not any other random type?
languages w/o them feel awkward since you’re generally limited to one statement per line
I went the "only let introduces bindings" route, and I'm pretty happy so far:
if (left.next(), right.next())
... is (Some(let l), Some(let r)) { /* use l and r */ }
... is (Some(let l), None ) { /* use l */ }
... is (None, Some(let r)) { /* use r */ }
... is (None, None ) { /* use nothing */ }
}
Some of the earlier ones remind me of C#'s records. Were they inspired from them?
No, that stuff is much much older.
Named parameters are problematic because of parameter names becoming significant to the API. See Python’s * and / in parameter lists (like def foo(a, *, b) for example).
I think the name problem is overblown, you can always have an annotation to facilitate name changes.
I would be deeply uncomfortable to work in an environment where one couldn't ask the author of a change for insights or rationale, because the author let some machine write it and therefore lacks any deeper understanding.
I think it's due to multiple reasons, and the threshold of rejecting the course of GitHub/Microsoft/the USA seems to have reached a level where GitHub stopped being the "default" place to be for a number of projects already.
And if you are at a point were you need a Codeberg account anyway already, why not move your own projects there (or use it for new ones)?
Not to mention, the Forgejo project is at a stage were it feels like your bug report/feature request/contribution has an actual impact.
As someone also working on a minimal programming language, I might share some of the values, but using Go as an implementation language is an immediate turnoff.
Also, not having a single code example on the linked page is super-annoying.
And all of this due to the mistaken design decision to stick with the obsolete readiness-based model instead of going with the superior completion-based model.
(You can build a readiness-based API on top of a completion-based API, but not the other way around.)
git worktree is just so much easier to work with if you want to work on multiple versions or branches of some code.
It allows having multiple IDE instances open, all fully functional and indexed, and handing over commits from one worktree to another without having to fetch constantly in between.
Trying to emulate this with multiple clones feels like trying to do OOP in C -- sure one can do it, but it's pointless hassle compared to a fleshed-out solution that works right out of the box.
Not to mention it's so much faster and more efficient than git clone.
Thanks for your reply, some replies below!
Not sure, maybe my wording isn't clear enough. What I intended to say is that arguments can be named, not that they have to. In any case, the order of arguments must match the order of parameters, named or not.
That removal could actually happen, so I didn't list it. (Rust started requiring
dynand disallowed naked trait returns with edition 2018. So dropping theimplin that position might not be completely impossible like the other uses ofimpl.)Yes, just methods.
You can have both – that's what's being made possible by them not being in a hierarchy.
It's a bit late for that, isn't it? ;-)
What value is provided by keeping it? Why a syntactic special-case for exactly that type and not any other random type?
Then fixing that might make sense. :-)