> An interesting outcome of removing coherence and having trait bound parameters is that there becomes a meaningful difference between having a trait bound on an impl or on a struct:

This seems unfortunate to me.

You depend on crates A and B. A impls Foo for Bar. You pass an instance of Bar to a function that accepts `impl Foo`. You are happy. Later crate B adds an impl of Foo for Bar. Clearly _at least_ one of these must be an orphan impl, but both could be. Suddenly it's ambiguous which implementation of Foo you're talking about, so you break because B added an impl.

There are many potential problems of this flavor with letting any `impl Trait for Type` be an orphan impl and then referenced by path. What happens, for example, if an impl that was an orphan impl in one version of A becomes a coherent impl in a later version of A?

I think there has to be special syntax for named/path-referenced/symbolic impls, even if the impl does not have an identifier name, so that the compiler can know "this impl only resolves if you tell me _specifically this impl_" and the impl provider has a way to create a solid consumer contract about how to use that impl in particular.

Also, not having an identifier name would mean you can't have different impls of Foo for Bar in the same module. That's probably not a limitation anyone would care about, but it's there.

I also don't see an issue with having multiple impls of the same trait, as long as they don't provide duplicate items inside a module. I often do multiple impl blocks to break up larger logic and organize docs, though this is generally not for trait impls, but I don't see why it couldn't be.

Let me be clear though, I'm not saying this is the best path forward on the coherence/orphan situation necessarily, just a minor critique of the blog posts position. This is a famously tricky issue, and I suspect there is no silver bullet here. Though I have always wanted some way to add flexibility to the orphan rule.

I think that's fine. Same as what happens if B adds a new function with the same name as a function in A that you were using unqualified.

> What happens, for example, if an impl that was an orphan impl in one version of A becomes a coherent impl in a later version of A?

Nothing much?

1. App tabs improves UX for 99.999% of users who aren't using a WM with a good tab solution (if one even exists).

2. WM tabs means launching a new app instance for every tab you might want vs having lightweight app tabs.

3. App tabs can do all sorts of app-level things and UX polish that dumb WM tabs can't do because they are so general. My terminal emulator tabs show a badge count of bell notifications, can be dragged around into groups, or dragging into other tabs as split panes. My browser tabs show you which tab is playing music and can impl right click -> mute.

4. I bet even the biggest WM tab cheerleader still uses browser tabs.

5. WM tabs are a different concern than app tabs, not a replacement. WM tabs are useful when you want tabs and the app doesn't provide a good tab metaphor or when you want to tile/group app instances a certain way. That doesn't mean it's not useful for the app instances themselves to have app tabs when it makes sense.

Although while I usually like tabs for most apps, I don't use tabs for terminal and rely either on window manager or tmux. I guess the difference is that I often want a mix of tabs and having multiple terminals side by side, whereas I don't really need that for a browser (or very seldom)

Sway had the better, though often tedious, WM tab solution that I've tried. Niri had a useless one.

I really tried to love sway splits and tabs for terminal windows. But I finally admitted I'd rather just alt-tab to a few different terminal apps, each with its own concern (maybe one per project, this one for my remote machine), and best of all, each with its own internal tabs.

That said, tabs in kitty and tmux, for example, are so basic that you don't necessarily lose much if you were to use WM tabs instead.

On the other hand, tabs in iTerm2, Ghostty, Cmux, probably macOS Terminal -- a bit more powerful and intuitive since you can do things like drag them, and they can show info like terminal state. And in some of those apps, they can be displayed vertically which is my favorite.

One of the reasons why I use tmux rather than i.e. iterm2 tabs is that I don't have to change any of my habits or learn extra shortcuts when I'm working with ssh.

- https://fluxbox.org/features/

https://github.com/niri-wm/niri

Sometimes, it makes perfect sense. The reason tabs made sense for web browsers since 2004 is because each web page could be thought of as a “stateless” instance of an application. You’re not asking for “tabs”, you wish every application could be “Stateless”. Stateless is a beautiful thing, until you understand what state is, and who needs to manage it.

If every “tab” of Spotify had no idea what the other “tab” is playing and you had to switch back and forth between tabs to pause-and-play songs, that would be a bug, not a feature. While 2 “windows” playing audio (if you instruct them to) is expected.

Agreed, and this is why tabs need to work at the app level, not window manager/os level.

That said, for Spotify specifically, it can already tell what I'm playing on an entirely different device. I think they can handle tabs.

Of course this might change in future. And Mac OS has other popups where there is no “skip” and only “remind me later”.

Nobody can predict what Apple will do tomorrow, but as of today, they aren't really pushing Siri/Apple intelligence really hard particularly after initial setup. None of most of the above for example.

I don't know what happens with Home Edition, but I though the pushback was mainly from Insider Preview?

You can't even select a cell on notepad without a freaking copilot button pooping up every single time. Same on word, that's maddening !

You could argue that windows isn't Microsoft copilot 365, but then, why do people even use windows ? It's always because of the office, my bad, copilot 365 suite.

I actually trust the Apple Intelligence, when off, doesn't exfiltrate my data.

I too would not want any unprompted access to my files.

At the end of the day this issue is that we don't trust the OS and we cannot easily validate how it is designed to behave.

Baked into the OS implies that it's integral to its operation in a way that the two are fundamentally inseparable. Having a global off switch implies that's not true.

There are other irritating baked in aspects of the newest macos and other recent versions that are arguably less avoidable, like Tahoe's entire UI design, or the Settings app.

Maybe it's doing stuff that doesn't rise to my level of attention, but it isn't actively annoying me.

It's clear to me as a more seasoned engineer that I can prompt the LLM to do what I want (more or less) and it will catch generally small errors in my approach before I spend time trying them. I don't often feel like I ended up in a different place than I would have on my own. I just ended up there faster, making fewer concessions along the way.

I do worry I'll become lazy and spoiled. And then lose access to the LLM and feel crippled. That's concerning. I also worry that others aren't reading the patches the AI generates like I am before opening PRs, which is also concerning.

I don't see why I would want magsafe on my phone at this point.

I've been charging my 13 Pro exclusively via MagSafe for a couple of years... out of necessity. The charging port has... an issue... and I've yet to get it resolved.

Honestly the only time I miss being able to use the charging port is on flights, where I'm using someone else's charging solution (i.e. a port I can plug in to).

Everywhere else (bedside table, in the car, or even out and about) it's MagSafe.

The only downside to this approach is that you need to be more specific about which case you buy (they don't all support MagSafe) but in terms of convenience it's night and day better.

Good for bedside table too, but not a game changer.