#rust-lang

ubsan: sorry, never had a chance to get back on IRC yesterday, what's up?

nmatsakis: Ping. I'm discussing with pnkfelix right now and we have questions about macro stuff.

ok

First question: is nrc the primary person for macros 2.0 (as in ‶rewrite-rules-based macros″, not procedural ones).

s/./?/

Leo`: yes

he's been doing the most thinking about it

and writing the RFCs

I think we've largely retrenched to macros 1.1 in terms of short term :)

but i guess that's more about procedural

Ok. :D Next question: do you know off-hand if he's planning on keeping non-terminals like expr, ty, etc, or just have token-tree based macros only?

I would love to just ha e a general-purpose $foo but that's not really possible

What do you mean?

Leo`: many current macros you couldn't translate

Leo`: Hmm; I don't think anybody has proposed removing non-terminals, but I also don't know that he has put that much thought into this aspect

I think we've been thinking more about hygiene

Mh ok.

and esp. hygiene for things other than local variable names

but I could be wrong

We're asking because I'm concerned that macros 2.0 does not make the same mistakes that macro-rules have regarding future-proofing, thuis kind of stuff.

one thing I had in mind is "scan until you find the token after the $foo"

i.e. so ($x; $y; $z) could take expressions, because they don't contain ;

eddyb: That's basically expressible with regular expressions I guess... ?

[^;]*

:P

with delimited sequences it's *almost* okay

Leo`: it's a good point!

but now if you do ($x, $y, $z)

and pass foo::<a, b>, c

Leo`: that's an argument in favor of a "macros 2.0" that I hadn't fully considered

you get them split between "foo::<a" and "b>"

yeah, sadly `<` and `>` is one of the things that just makes this plain hard

eddyb: Yeah < > are not considererd delimited tts by the parser.

maybe this is indicative of just how bad <> are

Yup.

and it would work otherwise

not 100% sure though

though you could certainly imagine

schemes where you tell the parser how to treat them

you also can't capture individual tokens this way

e.g., "type-like"

or "expr-like"

That also falls outside the expressivity of regular-expressions.

basically i'm imagining nonterminals

but not tied to the current grammar per se

nmatsakis: I sort of want the $foo system to be expanded in a way that you can delegate to other macro_rules macros

yes, I've seen some work in the context of Racket

not sure what exactly it should do though

where you can write more of a grammar

nmatsakis: pnkfelix is recommending me to have a meeting with nrc to discuss this, would you be interested in participating as well?

Leo`: possibly :) I saw talk to him about it, let me know when it is

*say

otherwise I'll just pick your brains later

Ok ok.

nmatsakis: boop

ubsan: what's up

nmatsakis: I want to talk about casts

and something else

ok

let me check

oh, right, and transmute_copy

ok

so, first transmute_copy, because I think it's a simpler thing

basically, I think the function would be more useful if it took <T: ?Sized>

ubsan: transmute_copy is just ptr::read

why do we even have it as a function?

arielby: because it is a function now

ubsan: yeah stability

but

because someone thought it was a good idea to stabilize

also, it's not ptr::read

ubsan: no

it's memcpy

because it was present since 1.0.0

pub unsafe fn transmute_copy<T, U>(src: &T) -> U {

ptr::read(src as *const T as *const U)

}

nothing more

nothing less

because otherwise, that would be hella UB

well

fun

I'm fairly certain that's hella UB, unless ptr::read for some reason doesn't take an aligned parameter

ubsan: transmute_copy requires alignment

arielby: why?

because it is ptr::read

like, why should we do that?

we should have `ptr::unaligned_read`

or something

if we want an unaligned read API

I disagree

unaligned read vs. aligned read

is orthogonal to random casts

transmute_copy should just memcpy

so... why is that UB? It seems to me that it... may be UB?