These are chat archives for rust-lang/rust

4th
Mar 2019
Diego Antonio Rosario Palomino
@GunpowderGuy_gitlab
Mar 04 01:35
hey , i have been thinking about porting the modern iteration of the build engine , eduke32
to rust
Diego Antonio Rosario Palomino
@GunpowderGuy_gitlab
Mar 04 01:41
i would have thought twice if it used a restrictive license such as gpl
the one used is arguably worse , but on the upside , was crafted by the creator of the engine , ken silverman himself
could i ask him to relase a new version , so the modern source port people have worked over the years
retroactively uses a liberal license ?
GiantCowFilms
@GiantCowFilms
Mar 04 03:33
I have two lifetimes with the same name, but the compiler is claiming they are different. Could someone explain why?
 pub async fn handle_message<'a>(message: &'a Message, sink: &'a Sink<SinkItem = Message, SinkError = Error>) {
                                           ^^                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ different lifetime here
                                           |
                                           first lifetime here
John
@onFireForGod_gitlab
Mar 04 03:38
just make two liftetimes?
GiantCowFilms
@GiantCowFilms
Mar 04 04:16
I tried that already. I got error[E0709]: multiple different lifetimes used in arguments of async fn.
Joey
@OddCoincidence
Mar 04 04:18
async fn doesn't support multiple lifetimes yet rust-lang/rust#56238
Tom Jakubowski
@tomjakubowski
Mar 04 09:16
OsStr's unix implementation does a transmute to convert a &[u8] to &Slice where struct Slice([u8]). Is this kind of thing safe/defined behavior in general? I didn't see any language items on OsStr, so it wouldn't seem particularly special in the eyes of the compiler.
Zakarum
@omni-viral
Mar 04 09:17
Does struct Slice([u8]) has #[repr(transparent)] or #[repr(C)]?
In either case, I guess, std can rely on rust layout, unlike us - mere mortals
Same as Path is str under the hood
It wouldn't make much sense for a type with single non-ZST field to have different layout than this field
Tom Jakubowski
@tomjakubowski
Mar 04 09:20
Slice doesn't have #[repr(transparent)]. and actually it's struct Slice { pub: inner [u8] }, if that makes a difference
Zakarum
@omni-viral
Mar 04 09:21
Well, It's std. It can do some stuff that we can't
Tom Jakubowski
@tomjakubowski
Mar 04 09:21
I am very wary of transmuting slices - I instead cast the pointers and adjust the lengths as needed (making sure the alignments and length is compatible with the cast)
Zakarum
@omni-viral
Mar 04 09:21
If you transmute from &[T] to &[U] it should be safe in case transmuting from &T to &U is safe
Including equal size and compatible alignment
Michal 'vorner' Vaner
@vorner
Mar 04 09:23

I think for the original question, missing repr(transparent) is a bug and should be fixed, std or not. Even it if it might be safe in std for now, it might stop being safe some time in the future and nobody would notice it breaks ‒ and the transparent thing here (if its safe) is just a no-op in practice.

@tomjakubowski I think you have an opportunity to get a patch into rust itself ;-)

Zakarum
@omni-viral
Mar 04 09:24
@vorner You're right. I just think all those things weren't revisited sinse repr(transparent) was added to lang
I got my patch in rust repo last year, so you @tomjakubowski can do it yourself ;)
Ingvar Stepanyan
@RReverser
Mar 04 13:57

If you transmute from &[T] to &[U] it should be safe in case transmuting from &T to &U is safe

Well not really, it's safe only if transmuting T to U is safe (I think this is what you meant by the next sentence)

for example, with

#[repr(C)]
struct S {
  x: u32,
  y: u8,
}

transmuting &S to &u32 is safe, but &[S] to &[u32] is not

Roman Proskuryakov
@kpp
Mar 04 20:58
Hi, due to adding const fn are you going to add pure const closures (possible name FnConst to group of ops Fn|FnOnce|FnMut)?
Zakarum
@omni-viral
Mar 04 20:59
FnConst is kinda Fn but further restricted?
Roman Proskuryakov
@kpp
Mar 04 20:59
Yep
Zakarum
@omni-viral
Mar 04 21:00
Is const fn allowed for trait methods?
Roman Proskuryakov
@kpp
Mar 04 21:01
trait fns cannot be declared const
Zakarum
@omni-viral
Mar 04 21:02
Well. Then FnConst is impossible for a while
Roman Proskuryakov
@kpp
Mar 04 21:02
Why?
Zakarum
@omni-viral
Mar 04 21:02
Because it will be trait FnConst<A>: Fn<A> { const fn call(&self, args: A) -> Self::Output; }
Roman Proskuryakov
@kpp
Mar 04 21:04
why const fn call? You don't need it to be const fn call, you need to check whether the code inside a || closure satisfies const fn requirements
Zakarum
@omni-viral
Mar 04 21:05
Well. It would be useless unless you will be allowed to call in the const context, no?
Denis Lisov
@tanriol
Mar 04 21:06
Also, why FnConst only? I'm not sure whether something like FnOnceConst makes sense under the current model... but at least I see no fundamental problems with it.
Roman Proskuryakov
@kpp
Mar 04 21:07

Well. It would be useless unless you will be allowed to call in the const context, no?

Oops. I see. Thanks.

Well this is an x-y problem. I have just discovered STM(Software Transactional Memory) and I would like to restrict the code inside a transaction to pure const. How can I do that?

Have a look at the example of stm crate:
use stm::atomically;
atomically(|trans| {
    // some action
    // return value as `Result`, for example
    Ok(42)
});
Zakarum
@omni-viral
Mar 04 21:10
@kpp you can't, but Fn is pretty close to it
Unless there are internal mutability in function's state
Roman Proskuryakov
@kpp
Mar 04 21:10
That's why I want FnConst =)
Or ConstFnMut (OMG)
Denis Lisov
@tanriol
Mar 04 21:11
Technically, why not? Seems to make sense :-)
Roman Proskuryakov
@kpp
Mar 04 21:11
Or even let it be only FnConst, as we all know you can take outer variable, modify it and return instead of creating ConstFnMut
Zakarum
@omni-viral
Mar 04 21:12
If state changes breaks your safety guarantees you'd have to stick unsafe on yout functions.
But in any case you can just put in documentation that interior mutability shound't be used there
Roman Proskuryakov
@kpp
Mar 04 21:13
You can just put 200+ UBs in the Standard (no).
Zakarum
@omni-viral
Mar 04 21:13

ConstFnMut

Two days ago I read that constexpr a = f(); constexpr b = f(); static_assert(a != b); can compile in C++.

Roman Proskuryakov
@kpp
Mar 04 21:16

whereas

constexpr state = 0;
constexpr a = f(state);
constexpr b = f(state);
static_assert(a != b);

should be fine?

Zakarum
@omni-viral
Mar 04 21:18
I don't think so
But it still can compile in C++ given very sophisticated f
Dodo
@DutchGhost
Mar 04 22:11
Does Miri catch unsound transmutes?
Andrea Stevanato
@thymbahutymba
Mar 04 22:24
if i have something like let s = "my_func" how i can call my_func starting from this String?
Denis Lisov
@tanriol
Mar 04 22:25
Manually (match / map of strings to functions).
Andrea Stevanato
@thymbahutymba
Mar 04 22:26
is unknown, the name can be whatever I want
Denis Lisov
@tanriol
Mar 04 22:27
You mean calling any arbitrary function from your application? No standard way.
There may be some platform-specific tricks, but not nice ones.
Andrea Stevanato
@thymbahutymba
Mar 04 22:27
I want something like let s = "my_func"; (s)();
Denis Lisov
@tanriol
Mar 04 22:27
What are you trying to do in such a strange way?
Andrea Stevanato
@thymbahutymba
Mar 04 22:28
proc macro that create a slice of function pointer
Denis Lisov
@tanriol
Mar 04 22:29
Well, you can try generating a list of functions that can be called in such a way, but does it really make sense?
Andrea Stevanato
@thymbahutymba
Mar 04 22:30
this is what i would: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3d0fbe1e27a389ed506d17051094b2d4 and then my proc macro "task" will create &[fn()] that contains all this function pointer
so starting from string I wish to have the possibility to call the function
Denis Lisov
@tanriol
Mar 04 22:32
IIUC, proc macros are not guaranteed to have any way of persisting data between invocations.
Then you can try to store the name together with the pointer and then lookup the function by name.
Andrea Stevanato
@thymbahutymba
Mar 04 22:33
this will be the second problem
the problem is "how i can get the pointer" ?
Denis Lisov
@tanriol
Mar 04 22:34
The macro can generate code that refers to the function by name. Unless it's private to a submodule.
Andrea Stevanato
@thymbahutymba
Mar 04 22:35
so i need a macro and a proc_macro for do this stuff?
Ingvar Stepanyan
@RReverser
Mar 04 22:36
no, "the macro" == "proc macro"
Andrea Stevanato
@thymbahutymba
Mar 04 22:41
I know the function name, but how i call this once I know it?
Denis Lisov
@tanriol
Mar 04 22:42
There's no builtin way to call a function by name.
You have to find the function pointer, not the function name.
Andrea Stevanato
@thymbahutymba
Mar 04 22:43
you have some advice for find the function pointer? :D
Denis Lisov
@tanriol
Mar 04 22:51
Have you thought about something like this?
Andrea Stevanato
@thymbahutymba
Mar 04 22:53
of course, in that call I'll use static TASK: &[fn()] = &[my_first_task, ...] but i want to figure out something with proc_macro
Denis Lisov
@tanriol
Mar 04 23:30
Your macro can generate a hashmap instead of a slice so that you can find the function in the hashmap easily. What's the problem with this?