Convert a boolean into a string

What could go wrong? I was recently spelunking through the Cornstack/nomic training dataset, the massive corpus of code that feeds some of our modern AI overlords, when I noticed something amusing. One of the queries in that dataset ask how to “convert a boolean to a string in PHP,” expecting the literal words 'true' and 'false'. Not the worst query to be submitted, and not the hardest either. Than, you start thinking about it.

Take a second. Guess what it is.

I’ll give you a hint: it’s not json_encode. It’s not var_export. Keep that guess in your mind, and let’s talk about why this seemingly trivial task is a fascinating glimpse into the PHP ecosystem.

The Native PHP Trap

If you are a junior developer, or an AI trained on basic type juggling, you might innocently try this:

<?php
$str = (string) true;  // yields "1"
$str = (string) false; // yields ""
?>

Ah, PHP. Beautiful, wild and chaotic PHP. It looks at your boolean, shrugs, and turns it into the classic string 1 or an agonizingly empty string "". Yet, everyone knows that '0' is false.

But we don’t want "1" and "". We want the literal strings 'true' and 'false'. Because PHP doesn’t do this natively, we are forced to get creative. And if there is one thing PHP developers are, it’s creative.

The Menagerie of Solutions

Over the years, I’ve seen practically every way to skin this particular cat. Let’s look at the lineup:

The Array Index Hack

<?php
$str = ['false', 'true'][$bool];
?>

Every time I see this in a legacy codebase, I picture a developer in 2007 leaning back in their chair, smiling at their monitor like they just defused a bomb. It works because PHP implicitly casts false to 0 and true to 1. It’s clever, but clever code is a gift you give to your future self, and your future self hates you.

The JSON Party Trick

<?php
$str = json_encode($bool);
?>

This is actually brilliant in its own way. JSON natively uses lowercase true and false. So, json_encode(true) returns the string "true". It feels a bit like using a sledgehammer to crack a peanut, and there’s a tiny bit of function-call overhead, but it’s undeniably neat.

The var_export Side-Door

<?php
$str = var_export($bool, true);
?>

var_export is meant to give you a parseable PHP representation of a variable. For booleans, that happens to be lowercase. It works, but using a debugging function for production string manipulation feels like wearing your pajamas to the office.

The Modern match

<?php
$str = match($bool) {
    true  => 'true',
    false => 'false'
};
?>

Ah, PHP 8. Clean, explicit, and beautiful. No type juggling magic, no hacks. Just pure, readable intent.

<?php
switch($bool) {
    case true: $st = 'true';
    case false: $st = 'false';
}
?>

And, of course, switch() is also possible. I couldn’t resist mentioning it here, for the old timers.

The Reveal

So, back to the Cornstack/nomic dataset. What does the AI overwhelmingly choose?

You guessed it: The Ternary Operator.

<?php
$str = $bool ? 'true' : 'false';
?>

Why? Because the AI was trained on twenty years of PHP code. For two decades, the ternary operator was the undisputed, idiomatic way to solve this problem. It’s fast, it requires zero function overhead, and any PHP developer from version 4 onwards can read it in their sleep. The AI isn’t wrong; it’s just chronologically stuck.

Moving Forward with Idiomatic PHP

This little exercise highlights a much bigger conversation we need to have in the PHP community.

We are standing at a crossroads. On one side, we have the LLMs, trained on mountains of legacy code, eagerly regurgitating the patterns of 2015 because they are mathematically probable. On the other side, we have modern PHP, PHP 8.0, 8.3, and soon 8.6!, which gives us match expressions, enums, constructor property promotion, and readonly properties.

If we just blindly accept the code our AI assistants hand us, we risk cementing old idioms forever. The ternary operator for boolean-to-string conversion isn’t bad, but is it the most modern or expressive way to do it in 2026? Probably not.

We need to actively promote and use modern, idiomatic PHP. We need to write match expressions not just because they are shiny, but because they explicitly communicate our intent. They force us to handle edge cases. They make our codebases look like they were written yesterday, not a decade ago.

Don’t let the training datasets dictate the future of your code. Write the PHP you want to see in the world. And hey, maybe one day, when we retrain those models on modern codebases, they’ll finally learn a new trick.