I had commented something similar to stating it was possible to pass the inference problem to the struct if the goal was to support more types, but I removed it because I didn’t think my example was easy to understand when reading it later. I made a better example though

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8651fa6121840658b4b6249399f693c7

I made an edit.

There’s not anything stopping it from supporting Option<&str> though. This would be the implementation

impl OptionUpgrade for Option<&str> {
    fn upgrade(self) -> Option<String> {
        self.map(|v| v.into())
    }
}

It’s also possible to just make it generic over Option types

impl<A: ToString> OptionUpgrade for Option<A> {
    fn upgrade(self) -> Option<String> {
        self.map(|v| v.to_string())
    }
}

Two of your macro rules are not used 😉 (expand to see which ones).

The macro rules are all used. (Macros are matched from top to bottom by the declared match types. The ident/expressions can’t match until after the more text based Option matching.)

let _foo = Span { line: 1, column: 1, file_path: None };
let _bar = Span { line: 1, column: 1, file_path: "file.txt".upgrade() };
let _baz = Span { line: 1, column: 1, file_path: Some("file.txt".to_string()) };
let _baz = Span { line: 1, column: 1, file_path: None };
let _baz = Span { line: 1, column: 1, file_path: borrowed.upgrade() };
let _baz = Span { line: 1, column: 1, file_path: owned.upgrade() };

This doesn’t support Option<&str>. If it did, we would lose literal None support 😉

I didn’t make Option<&str> an option because the struct is for type Option<String>. It does support Option<String> though.

impl OptionUpgrade for Option<String> {
    fn upgrade(self) -> Option<String> {
        self
    }
}

It looks like the following, and uses the last match case.

let opt: Option<String> = Some("text".into());
let opt = span!(1, 1, opt);

With macro expansion

let opt: Option<String> = Some("text".into());
let opt = Span { line: 1, column: 1, file_path: opt.upgrade() };

There’s not anything stopping it from supporting Option<&str> though. This would be the implementation

impl OptionUpgrade for Option<&str> {
    fn upgrade(self) -> Option<String> {
        self.map(|v| v.into())
    }
}

One option to OP’s problem is to use an auxiliary trait implemented on both string and Option<string>

This looks something like the following

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=aa68fe540dbd09821ecc482423227b46

I clearly didn’t read it. It makes sense, if users aren’t visiting the API then it really doesn’t matter that it’s not redirected on insecure connections.

I disagree.

You shouldn’t serve anything over http. (The article argues that there’s risk of leaking user data) Whatever you’re using for a webserver should always catch it. A 301/308 redirect is also cached by browsers, so if the mistake is made again, the browser will correct it itself.

If you make it fail, you’re just going to result in user confusion. Did they visit the right website? Is their internet down? etc.

It’s not possible to follow Mastodon users on Lemmy yet. It is possible to @ them to a post or comment, they can follow users here, and they can also make posts and comments here after being pinged. (or searching for a post on Mastodon)

The issue is related to the binding being reassigned then never used. It’s happening because they’re using code generation where the final loop doesn’t need to assign. (but previous loops use the assignment at the loop start. Just throwing all that in a function and adding the warning suppression fixes it.

edit: I’m wrong, using an underscore works

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2ccac2a848523cb995b6c0efd92c569c

I misunderstood the reason the error was showing up. It seems like using a closure fixes it though.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=247730dfc1fbeeb8e2263ea3b95d6c0a

#[macro_export]
macro_rules! list {
    () => {
        None
    };
    [ $x:expr, $( $y:expr ),* ] => {{
        #[allow(unused_assignments)]
        let closure = move || {
            let mut first = cons($x, &None);
            let mut last = &mut first;

            $(
                let yet_another = cons($y, &None);
                if let Some(ref mut last_inner) = last {
                    let last_mut = Rc::get_mut(last_inner).unwrap();
                    last_mut.cdr = yet_another;

                    last = &mut last_mut.cdr;
                }
            )*

            first
        };

        closure()
    }}
}

I would expect the following to work

#[allow(unused)]
let mut last = &mut first;

1st choice counts makes it seem like people might have preferred the 3rd option. Anyway, I was an invalid vote is why I asked.

also note you will notice some numbers in the tables not being the same round from round, some people voted for the same option multiple times which means I couldnt give them a second or third choice since they only did 1 or 2

What happens to the vote if you step their 2nd and 3rd choice to less restrictive or more restrictive? (depending on the starting side)

I accidentally commented while still considering if I was going to comment.

removed

removed

removed

removed

removed

those devs understand why their assets are so large. but if you ask a js dev why they webpack instead of compiling they just start crying and run away