typo in summary corrected

Keeping in mind that your IDE could not possibly give you support for arbitrary 
properties on objects, they probably do support the @property phpdoc. Add that 
to __get/__set and you have

/**
 * @property string $StringMember
 * @property int $Counter
 * @property mixed[] $ArrayMember
 */
class Foo {
    private $data;
    public function __construct(array $data) { $this->data = $data; }
    public function __get($name) { return $this->data[$name]; }
    public function __set($name, $value) { $this->data[$name] = $value; }
}

$foo = new Foo([
    "StringMember" => "content",
    "Counter" => 42,
    "ArrayMember" => ["old" => "way"]
]);
$foo-> // should autocomplete/suggest StringMember, Counter, and ArrayMember

If you're talking about the {} syntax you used,
https://wiki.php.net/rfc/objectarrayliterals

I view as a strength of PHP, not having to declare all fields in a class. For example think of a class representing a HTML DOM element, like a link. It allow many fields, but most often you will only use some of them, like "href" or "class".

In my opinion the best syntax to write is something like:
$link = new Link(href: "target.html", class:"btn btn-info");

At the moment I use arrays:
$link = (new Link)->assign("href" => "target.html", "class" => "btn btn-info");

But the fields in the strings are messy and un-recognizeable.

Phpdoc is far too cluttering. Declaring every possible option is pointless for some classes, especially if they are highly dynamic, like derived from a database table.

So object literals. Getting to use names instead of strings.

Meanwhile

$object = new Object();
$object->StringMember = "content";
// etc

doesn't work?

Of course its working, this is not about a bug but about sleekness and PHP-to-programmer support ;-)

These assignment-lists are really lengthy and contain too many repetitions.

Its more like requesting the ternary operator instead of the "old" if ... then ... else ...

Just forgot to mention one more readability advantage:

It would support "nested" initializations, like it is now possible with arrays full of strings

$object = new Object({
    Property: $aValue,
    Property2: $aValue2,
    Subobject: new Object({
      ...
    })
});

I really hope we won't turn php into javascript :) Please take a look, the sugar you 
talk about is possible with the following 

class Props {
        function __construct(array $argv) {
                foreach($argv as $arg => $val) {
                        $this->$arg = $val;
                }
        }
}

$u = new Props(['hello' => 'world',
                'good' => 'bye',
                'obj' => new Props(['my' => 'god'])]);

Or even use func_get_args() to make $argv optional.

However this is a VERY bad style. Every object property should be defined with the 
class.

What i mean, each property should be contained in the class declaration before 
it's actually defined in construct :)

I think the main point was missed: Original request was about Named Parameters. (http://en.wikipedia.org/wiki/Named_parameter)

This will not extend the language or its features but enhance code readability for both humans and IDEs.

Hi, would really like to see this feature.

@ab, you did not understand the main request. Arrays *are* possible, but THESE are the bad style you talk about. Initializing properties by strings is error prone, since it is a concept brake: mapping anything-strings to defined-constants.

The OP talked about named constants in constructors. What is the problem with such a language feature?

If anyone votes for "properties shoudl be defined in the class", why does php support magic setters and getters?