Unfortunately SilverStripe 3 doesn't work with PHP7 out of the box due to some naming conflicts with newly reserved words. Some community members already fixed the problem. But how can we easily use this in our daily work, as the fix will be available in SiverStripe 4? "Semantic versioning", you know...

First Thomas Portelange made a migration script you can run on your own framework fork (or the server if you're brave, but that's not recommended for security) which simply renames some classes and injects them again so your code isn't affected. This works fine for SS3.2 and up. Then Mark Guinn made a fork of SilverStripe Framework with this patch applied (and some other minor tweaks) you could include in your composer.json.

Unfortunately Mark's time with SilverStripe is very limited and so he doesn't update his fork. I also tried to fork the framework and keep it up-to-date, but that could become tricky. So kinglozzer gave me the great tip, that there is a composer plugin that can install a patch after running composer install. I took Mark's work, put it in a patch and wrote a very simple module (basically just a composer.json) you can include easily in your projects and enjoy the more gain PHP7 gives to you (about 25-30% faster websites!)

Simply run

composer require wernerkrauss/silverstripe-3-php7

and you're done.

Note: Currently this works with SS3.2 and up, I also tried to patch a site that still runs on 3.1, but that led to problems with the RSS feed. The current patch will fail on 3.1, cause some patched files have been invented later.

Update 17.01.2017:

Recently I had some troubles deploying to a server and switching to PHP7. This was because i used PHP 5.6 to run composer and dev/build/flush, so silverstripe-cache was built with PHP5.

You can run composer on PHP7 with the --ignore-platform-reqs parameter, so it doesn't complain that SilverStripe 3 can't run on PHP7. Also be sure to build the manifest with the same PHP version, because when you use the silverstripe-cache folder in your webroot, the cache isn't prefixed with the PHP version, just user. If you have the cache inside /tmp/ this won't occur (but then you'd have to flush in the browser again). Thanks to Lukas for helping me fix this issue.