Why Objective-C

Post by umpalumpaaa » Tue, Mar 03, 2026, 5:31 AM UTC

andrekandre wrote: post #109

ardit33 wrote: post #104

Earlier quoted context omitted.

I hate how pendantic and useless some of the features of swift being pushed down by academics that don't write apps or services themselves. Simple example: Objective-C if myObject { } in swift if myObject != nil { } Also opitionals in swift could have totally be avoided if they adopted a prototype based langue (basically object are never nil). Lua did this, and it is very elegant But meanwhile, we got a half backed o…

> you still can crash an app doing myArray[1] the first thing i do when starting a new project: extension Array { subscript(safe: Int) -> Element? { ... } } there was talk in the swift forms about adding that as standard that but it seems to have died off... [0] https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...

Post by Someone » Tue, Mar 03, 2026, 5:42 AM UTC

zer0zzz wrote: post #52

nicoburns wrote: post #39

Earlier quoted context omitted.

> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting. I think the way to think about it is that with Rust, it's as if all…

Except the entire design of swift is meant to make everything more automated. * automated exclusivity with value types and value witness tables, classes as arc types (ie Arc >) * automated interop with C/C++/Obj-C through the clang ast importer Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved? Source: I worke…

Post by catoc » Tue, Mar 03, 2026, 7:09 AM UTC

peyton wrote: post #121

catoc wrote: post #56

Earlier quoted context omitted.

It is a really pleasant language, but I think the annotation is for initialization only - compiler checking against initializing an object ptr with a null value - and does not prevent crashing when addressing an already released object

> does not prevent crashing when addressing an already released object I don’t know what behavior you’d expect here or in what situation you’d encounter this for a nonnull reference. You’d have to be really living dangerously I’d imagine. The footgun was that nonnull isn’t enforced. And anyway, leaks were more the issue.

Post by pjmlp » Tue, Mar 03, 2026, 8:26 AM UTC

vintagedave wrote: post #3

I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy,…

Post by pjmlp » Tue, Mar 03, 2026, 8:36 AM UTC

jcelerier wrote: post #106

coliveira wrote: post #59

Earlier quoted context omitted.

C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.

how would you write something like #include #include #include int main(int argc, char** argv) { using namespace std::literals; std::string foo = "foo:"; foo += argv[0]; std::map m{ {foo, 123} , {"count: "s + std::to_string(argc), 456} }; std::println("{}", m); } in C

    import std;

    int main(int argc, char** argv)
    {
        using namespace std::literals;

        auto foo = "foo:"s;
        foo += argv[0];

        std::map m{
          {foo, 123}
        , {"count: "s + std::to_string(argc), 456}
        };

        std::println("{}", m);
    }