@BordedDev Re: Also := will be colon equals

or ... we call it SKYRIZI!

(sorry, the 14 yr old still lives inside)

@lorentz I also don't see why either is bad form

Think of this.. it's not uncommon to see C programmers do this...

if( ptr ) {/* */}

- technically exercises the knowledge that 0 is the definition of "false" at the machine code level & any other value is "true". It translates to "if the pointer is not nil then".

But it relies on a side effect of the C language at the time. There is no guarantee that in the future version of C won't define 1 as true and 0 as false and the such code could then have an "undefined" in the conditional.

In reality, it should be:

if( ptr != NULL ) {/* */}

- which is self documenting ;-)

This parallels Swift which **assumes** that "nil" is false in the

if( let x = y ) {/* */}

as the let x = y executes and leaves behind the x as in:

let x = y

if( x != nil ) {/* */}

and this discretely performs a legit boolean check, is truly self documenting, and is easily debuggable.

@lorentz Booleans are exactly as real as optionals too

I have not run the Swift construct down machine code or assembly yet, but the thrust is that optionals don't exist at the CPU level... the computer's machine code. It takes extra multiple lines of machine code to implement such a concept. A boolean in C is nothing more than a compare to 0 or not zero when it hits assembly. Exceptionally efficient down to the CPU cycle per machine code instruction level.

I have not investigated booleans in Swift at the assembly level yet, but what you said about booleans in Swift makes me apprehensive at an OCD efficiency level. 😱

@atheist fun fact, ALGOL is where ":=" started and it was popularized by Pascal circa 1970.

While I think it is kinda cool it is called the walrus operator, it is pronounced "set equal" where the colon is where the hands of the sprinter are on the track, the = is where the sprinter's feet are. Ready "set" go.. hence ":" is the "set".

Goo goo g' joob?

@kiki Re I only like common swift

Have to agree, lovely.

@iiii Re: What's wrong with C and C++ to be using Swift of all things?

My C conventions have carried through C++ and ObjectiveC. If I am going to convert them over to Swift, I would rather not try to maintain them in two very different languages, especially one that does not generally allow you to use pointers / hardware addresses

@Lensflare actually it technically (with plenty of thorns) does embedded. I'm adopting it to bare metal coding for a hardware project. It is no easy task and definitely shows the insanely buggy nature of Xcode... but it is in theory a generic IDE that executes against external tool chains.

(what?! Xcodesucks sticking up for Xcode? Sign of the apocalypse; what's next? dogs and cats living together?)

I feel your pain...

Swift is... inconsistent at best

lets just say that I did not have to put "func" in front of a method or function since Pascal and then it was either "procedure" or "function". Why on earth would a "modern" language revert to such primitive style?

But to add insult to injury, the inconsistency is that you only put 'func' in front of some methods in a Class but not all.. e.g. not in front of init(), deinit().

"func"? We don't need no stinkin' "func"!

@Lensflare Session: "Meet Liquid Glass" would have had a standing ovation if it were I person. 😉

@Lensflare In my experience command-click or option-command-click does not always work. Nothing happens for instance when command-clicking on "padding". Xcode Does suck you know... 🤣

@Lensflare Digging through AI interaction on why that line causes the obscure error output, it very clearly pointed out that the reason the assignment could only be performed during declaration is because Swift functionally converts the "var" to a "let".

Here is some fun.. figuring out what owns what...

put self in front of ".padding" like this:

self.padding( .horizontal, 20 )

It builds easily and runs and then shits its pants 💩👖 with

Thread 1: EXC_BAD_ACCESS (code=2, address=0x16f17ffd0)

In some thread that I did not create.

"safe" seems to mean "no pointers" and I guess nothing else. I guess any car without a stick shift could be called "safe" by that sort of logic. (Swift == Hype)

@Lensflare Re: give me an example? ... not enough space available?

small memory models in any firmware force disciplined use of resources. Firmware in your TV, in your refrigerator, in your smart lightbulb, your ring doorbell, your AirTag, your USB-C or Thunderbolt cable.

Most of the computers out there have tiny memory models. (just count your cables, subtract your laptops, desktops, phones and iPads, there's your minimal "most")

Apple just advertised Swift Embedded last year for the ESP32C6 system: https://developer.apple.com/videos/... and then doubled down this year telling us they are using it in Secure Enclave Processor found in their devices (this could be a major fuckup). Be aware that the ESP32C6 is fairly bloated for an "embedded" system; try to fit that into the lightening cable head! (LMAO)

@lorentz

Re: By that definition there aren't any safe languages

Yep, nailed it. No such thing as a "safe car" either. Safety is always the responsibility of the driver. Discipline is key.

Re: so safety as a concept can only apply to end-user software.

Nope, not at all. My shit has been running for over a decade, no crashes.

RE: Software that can't crash can be written in Swift relatively easily like any other by-value language, by avoiding the heap

Beg to differ. Avoiding the heap has nothing to do with no-crash software or firmware. You can blow out a stack easy enough. There is no such thing as "infinite memory". Managing your memory like a BOSS has everything to do with no-crash software.

@Lensflare Kudos to you for going literal and noticing the 'int'. I suspect my cranky side put 'int"' into the malloc().

I just listened to another WWDC25 session, the one on Improve Memory Usage and Performance with Swift. It feels like the problems I pointed out are known to the team but they may be in denial.

@12bitfloat @12bitfloat, I firmly believe that crashing a program is never acceptable or safe.

Imagine your steering column is drive-by-wire, a common feature in many cars today, and it’s written in Swift within the car’s firmware. Now, imagine if the software crashes.

Consider the scenario where your mother is on a ventilator, and its firmware is written in Swift.

What if the code for the predator drone was written in Swift?

I'm not sure when it became "ok" for an app to crash but I'm not likely to ever be "ok" with it. Crashing app means shit-code, just that simple.

@Lensflare

Ok, show me how to do this in Swift:

int *ptr =NULL;

ptr = ( int * ) malloc( sizeof( int ) );

if ( ptr != NULL ) {

// Allocation succeeded, use ptr

}

else {

// Allocation failed, handle error

printf( "Memory allocation failed.\n" );

}

Because god knows that memory is tight in a Thunderbolt connector head...

@Lensflare how about the basics. When Swift fails to allocate memory, there is nothing to check, not like a null pointer to check or even a 1984 (OSError) MemError(void) function to call… things just go sideways; software crashes.

Accordingly it doesn’t sound like a good idea to use Swift in things like automobile software, medical ventilators, X-ray machines, CT scanners, aircraft software, navy ship software, nuclear missile software, drones, SpaceX rockets, and so on.

@lorentz Seems like every board requires a ton of library support that you need to hunt and peck around to find. Hours of just getting "hello world" to compile and link in many cases.

@BlazeStorm91 as hypocritical as it sounds, I'm trying to create a system of using Xcode with this and get rid of the Arduino IDE. If I can't step through debugging code, I want to ditch it with a vengeance.

the lesson learned here is make sure you copy the content before accessing the mouse in any web-edit. Web editing is always risky compared to editing in a real app. 😉

Developing political software? No? Maybe does not belong on DevRant.

@Grumm It used to be that there was a data fork and a resource fork, or just one of the forks. It really worked well, especially the resource fork which was a binary precursor to .plist files. Elegant actually. But when storing such on Windows servers, in Windows you saw both file forks. Nothing was "invisible" on either side. Invisible files were a rarity. Now it's like the file system has STDs everywhere in the form of invisible crap.

@tosensei I wish DevRant threaded... Your Q&A, spot on.

@atheist 🤣

macOS

@Lensflare It says "safe" but still crashes. It makes me jump through hoops in its "help" with managing memory "For me". My non-swift software doesn't crash b/c of any memory handling... even when the machine runs out of RAM.

Having the runtime engine to support Swift is grossly inefficient. Then top that off with Swift not supporting bit level operations beyond ANDing and ORing...gah

The Swift business of (_) is bizarre, along with the other use of special symbols that feels like ADA. I'm fluent in C, C++ Objective C, Pascal, ObjectPascal, FORTRAN, a half a dozen assembly languages and three machine languages (aka hex code). Swift tries to obscure the "Machine" and remove it from the language construct. That whole "optionals" and "unwrapping" thing it does which has no relationship to reality in the computer itself, drives me nuts. In my mind it is a failure in the model of "not having to deal with memory". They need to learn from MS BASIC circa 1980s

@retoor Astute! (re layoffs). I had no illusion of any physical fitness at Microsoft (re 20) as there is clearly no mental fitness involved with this product.

OMG, Apple added wrap around screen mirroring to the AVP. I sit here with what is effectively a 8 foot by 25 foot virtual screen from my MacBook Air on my lap... floating above the dog in my back yard.. This is AMAZING. I worked this way all day and yes I had to stay plugged in with the AVP but damn it was worth it.

So counterpoint, Apple built future proofing into their goggles... and it is "holy crap" awesome.

More motorcycles... electric preferably.