Mixing
Can I name a pattern in Rust? [duplicate]
This question already has an answer here:
How can I store a pattern in a variable in Rust?
1 answer
I am using winit to create a window and get input from the user through the window. The window creates variants of the enum Event and passes it to a "callback function" (I am not sure how accurate this is) for processing.
I am using match statements to decide what to do with the event:
fn process_event(event: winit::Event) -> winit::ControlFlow /*potentially break EventsLoop and exit*/ {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
However, this is getting very noisy quickly. I am currently splitting all the different cases up into functions, so that I can make this code a bit more expressive, but in the end, the patterns remain this verbose. It would be very nice if I could give a pattern to match against a name, I mean something like this:
pattern quitEvent =
winit::Event::WindowEvent {
event: winit::WindowEvent::CloseRequested,
..
};
fn process_event(event: winit::Event) -> winit::ControlFlow {
match event {
quitEvent => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
Is this possible? Even better would be if we could alias a combination of patterns aswell, in an "or" manner.
rust pattern-matching aliases
asked Jan 1 at 18:01
stimulatestimulate
423415
marked as duplicate by Shepmaster rust
Users with the rust badge can single-handedly close rust questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 18:19
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
How can I store a pattern in a variable in Rust?
1 answer
I am using winit to create a window and get input from the user through the window. The window creates variants of the enum Event and passes it to a "callback function" (I am not sure how accurate this is) for processing.
I am using match statements to decide what to do with the event:
fn process_event(event: winit::Event) -> winit::ControlFlow /*potentially break EventsLoop and exit*/ {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
However, this is getting very noisy quickly. I am currently splitting all the different cases up into functions, so that I can make this code a bit more expressive, but in the end, the patterns remain this verbose. It would be very nice if I could give a pattern to match against a name, I mean something like this:
pattern quitEvent =
winit::Event::WindowEvent {
event: winit::WindowEvent::CloseRequested,
..
};
fn process_event(event: winit::Event) -> winit::ControlFlow {
match event {
quitEvent => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
Is this possible? Even better would be if we could alias a combination of patterns aswell, in an "or" manner.
rust pattern-matching aliases
asked Jan 1 at 18:01
stimulatestimulate
423415
marked as duplicate by Shepmaster rust
Users with the rust badge can single-handedly close rust questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 18:19
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
How can I store a pattern in a variable in Rust?
1 answer
I am using winit to create a window and get input from the user through the window. The window creates variants of the enum Event and passes it to a "callback function" (I am not sure how accurate this is) for processing.
I am using match statements to decide what to do with the event:
fn process_event(event: winit::Event) -> winit::ControlFlow /*potentially break EventsLoop and exit*/ {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
However, this is getting very noisy quickly. I am currently splitting all the different cases up into functions, so that I can make this code a bit more expressive, but in the end, the patterns remain this verbose. It would be very nice if I could give a pattern to match against a name, I mean something like this:
pattern quitEvent =
winit::Event::WindowEvent {
event: winit::WindowEvent::CloseRequested,
..
};
fn process_event(event: winit::Event) -> winit::ControlFlow {
match event {
quitEvent => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
Is this possible? Even better would be if we could alias a combination of patterns aswell, in an "or" manner.
rust pattern-matching aliases
asked Jan 1 at 18:01
stimulatestimulate
423415
This question already has an answer here:
How can I store a pattern in a variable in Rust?
1 answer
I am using winit to create a window and get input from the user through the window. The window creates variants of the enum Event and passes it to a "callback function" (I am not sure how accurate this is) for processing.
I am using match statements to decide what to do with the event:
fn process_event(event: winit::Event) -> winit::ControlFlow /*potentially break EventsLoop and exit*/ {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
However, this is getting very noisy quickly. I am currently splitting all the different cases up into functions, so that I can make this code a bit more expressive, but in the end, the patterns remain this verbose. It would be very nice if I could give a pattern to match against a name, I mean something like this:
pattern quitEvent =
winit::Event::WindowEvent {
event: winit::WindowEvent::CloseRequested,
..
};
fn process_event(event: winit::Event) -> winit::ControlFlow {
match event {
quitEvent => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue
}
}
Is this possible? Even better would be if we could alias a combination of patterns aswell, in an "or" manner.
This question already has an answer here:
How can I store a pattern in a variable in Rust?
1 answer
rust pattern-matching aliases
rust pattern-matching aliases
asked Jan 1 at 18:01
stimulatestimulate
423415
asked Jan 1 at 18:01
stimulatestimulate
423415
asked Jan 1 at 18:01
stimulatestimulate
423415
asked Jan 1 at 18:01
stimulatestimulate
423415
asked Jan 1 at 18:01
stimulatestimulate
423415
423415
marked as duplicate by Shepmaster rust
Users with the rust badge can single-handedly close rust questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 18:19
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Shepmaster rust
Users with the rust badge can single-handedly close rust questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 18:19
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
There are no aliases for patterns in Rust (1.31).
There are guard clauses, though, and they can invoke functions:
match event {
n if is_quit_event(n) => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue,
}
Would therefore be possible, and of course within the function you can do any computation.
Here, the function would be:
fn is_quit_event(event: winit::Event) -> bool {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => true,
_ => false,
}
}
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
Not intending to overoptimize, just interested if this is less efficient or harder to optimize because of the function call instead of an inline pattern. it does require and extra match statement and introduces a boolean value and a function call.
– stimulate
Jan 1 at 19:06
2
@stimulate: Well, first of all, yes it will be slower in Debug. In Release, it will depend whether the guard is inlined or not; with inlining there should be no performance difference... operative word being "should" since optimizers can be finicky.
– Matthieu M.
Jan 1 at 19:55
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are no aliases for patterns in Rust (1.31).
There are guard clauses, though, and they can invoke functions:
match event {
n if is_quit_event(n) => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue,
}
Would therefore be possible, and of course within the function you can do any computation.
Here, the function would be:
fn is_quit_event(event: winit::Event) -> bool {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => true,
_ => false,
}
}
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
Not intending to overoptimize, just interested if this is less efficient or harder to optimize because of the function call instead of an inline pattern. it does require and extra match statement and introduces a boolean value and a function call.
– stimulate
Jan 1 at 19:06
2
@stimulate: Well, first of all, yes it will be slower in Debug. In Release, it will depend whether the guard is inlined or not; with inlining there should be no performance difference... operative word being "should" since optimizers can be finicky.
– Matthieu M.
Jan 1 at 19:55
add a comment |
There are no aliases for patterns in Rust (1.31).
There are guard clauses, though, and they can invoke functions:
match event {
n if is_quit_event(n) => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue,
}
Would therefore be possible, and of course within the function you can do any computation.
Here, the function would be:
fn is_quit_event(event: winit::Event) -> bool {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => true,
_ => false,
}
}
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
Not intending to overoptimize, just interested if this is less efficient or harder to optimize because of the function call instead of an inline pattern. it does require and extra match statement and introduces a boolean value and a function call.
– stimulate
Jan 1 at 19:06
2
@stimulate: Well, first of all, yes it will be slower in Debug. In Release, it will depend whether the guard is inlined or not; with inlining there should be no performance difference... operative word being "should" since optimizers can be finicky.
– Matthieu M.
Jan 1 at 19:55
add a comment |
There are no aliases for patterns in Rust (1.31).
There are guard clauses, though, and they can invoke functions:
match event {
n if is_quit_event(n) => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue,
}
Would therefore be possible, and of course within the function you can do any computation.
Here, the function would be:
fn is_quit_event(event: winit::Event) -> bool {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => true,
_ => false,
}
}
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
There are no aliases for patterns in Rust (1.31).
There are guard clauses, though, and they can invoke functions:
match event {
n if is_quit_event(n) => winit::ControlFlow::Break,
_ => winit::ControlFlow::Continue,
}
Would therefore be possible, and of course within the function you can do any computation.
Here, the function would be:
fn is_quit_event(event: winit::Event) -> bool {
match event {
winit::Event::WindowEvent { // match against close request event
event: winit::WindowEvent::CloseRequested,
..
} => true,
_ => false,
}
}
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
answered Jan 1 at 18:18
Matthieu M.Matthieu M.
205k29279519
205k29279519
Not intending to overoptimize, just interested if this is less efficient or harder to optimize because of the function call instead of an inline pattern. it does require and extra match statement and introduces a boolean value and a function call.
– stimulate
Jan 1 at 19:06
2
@stimulate: Well, first of all, yes it will be slower in Debug. In Release, it will depend whether the guard is inlined or not; with inlining there should be no performance difference... operative word being "should" since optimizers can be finicky.
– Matthieu M.
Jan 1 at 19:55
add a comment |
Not intending to overoptimize, just interested if this is less efficient or harder to optimize because of the function call instead of an inline pattern. it does require and extra match statement and introduces a boolean value and a function call.
– stimulate
Jan 1 at 19:06
2
@stimulate: Well, first of all, yes it will be slower in Debug. In Release, it will depend whether the guard is inlined or not; with inlining there should be no performance difference... operative word being "should" since optimizers can be finicky.
– Matthieu M.
Jan 1 at 19:55
Not intending to overoptimize, just interested if this is less efficient or harder to optimize because of the function call instead of an inline pattern. it does require and extra match statement and introduces a boolean value and a function call.
– stimulate
Jan 1 at 19:06
Not intending to overoptimize, just interested if this is less efficient or harder to optimize because of the function call instead of an inline pattern. it does require and extra match statement and introduces a boolean value and a function call.
– stimulate
Jan 1 at 19:06
2
2
@stimulate: Well, first of all, yes it will be slower in Debug. In Release, it will depend whether the guard is inlined or not; with inlining there should be no performance difference... operative word being "should" since optimizers can be finicky.
– Matthieu M.
Jan 1 at 19:55
@stimulate: Well, first of all, yes it will be slower in Debug. In Release, it will depend whether the guard is inlined or not; with inlining there should be no performance difference... operative word being "should" since optimizers can be finicky.
– Matthieu M.
Jan 1 at 19:55
add a comment |
