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.

He also sold before the buyback which caused the stock to raise 7%~. If he was insider trading, it would have made sense to purchase before a buyback, then sell afterwards.

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;

removed

removed

removed

removed

removed

There was another discussion in /c/TechTakes@awful.systems

I personally think Sam is basically just a fall guy. From the YC comments someone commented

Another source [1] claims: “A knowledgeable source said the board struggle reflected a cultural clash at the organization, with Altman and Brockman focused on commercialization and Sutskever and his allies focused on the original non-profit mission of OpenAI.” [1] - https://sfstandard.com/2023/11/17/openai-sam-altman-firing-board-members/

OpenAI is back!

deleted by creator

Discourse (where I no longer work, so I shouldn’t really have that staff title any longer)

I understood the title as staff for rust on a discourse instance. It seems like I misinterpreted the rank, and it actually might mean that you were a developer for the Discourse forum software.

We just have to give them a good enough reason to do so, by achieving a modicum of unification through this group-follow proposal.

I didn’t really read the blog post very closely before commenting. It looks like the concern is more focused on how to create a global name system for communities that users understand. I don’t agree that it’s an issue for rust, but I do think it’s an issue for the fediverse in general. I’ll cover both quickly.

• I don’t think it’s an issue for rust

I think programmers likely understand the fediverse really well once they’ve used it. I am doubtful there are actually problems with programmers finding their communties, and successfully subscribing to them. I think Discord servers are more comparable to communities than subreddits to communities. On Discord, if a server doesn’t have a vanity address, it’s partially not a problem because users are actively searching out official services. For programmers, if the organization backing rust officially designates an instance, I think programmers will understand it.

In my other comment on LemmyRS, I actually saw the disorganization of the fediverse as a feature, not an issue.

• I do think this is an issue for normal users or services

I don’t think users understand it at all. I think it’s mostly hopeless to try to explain that this other website that seems similar to their home instance can be followed by returning to their home instance or installing this plugin that will link it for them. I think solving it as a client problem is likely a better approach. It seems like users surprisingly do comprehend how to send and receive emails, but I think there are still user interface problems that need to be solved for the fediverse.

I think trying to solve it at the federation level is likely a bad idea. In my opinion, it just seems like other federated services, like IRC and email, and even IP systems (IPV4 vs IPV6) have been very resilient to change. Though, I do think it’s possible to have changes merged into Lemmy.

• I view the name system as a feature for rust

There are multiple reasons, here are some

• Users on other instances can have their name associated with their organization, ex. president@whitehouse.gov
• It provides organizations the ability to promote other related communities. I really like that programming.dev controls the local communities on programming.dev, as I’m able to find a bunch of related content all at once instead of having to search it out.
• It prevents reddit-like problems from happening. No one can censor rust’s organization from their own instance, they just can remove it from their competing instance. Defederation isn’t really a risk because many instances will stay in federation.
• rust as an organization is able to moderate and group their communities better.
• I think it provides more diversity to how clients will change overtime. As an example, on an instance hosted by the rust organization, there could be really good rust language support, because the organization the develops rust cares about the language features on the forum

(Mastodon created the above clip)

deleted by creator