dpratt71 said:
W3bbo said:
*snip*
Thanks for the reply, W3bbo. To better explain myself, suppose that you want to define a property which is a collection of "Foo" objects, but you don't want to allow adding or removing items via the property (i.e. the collection is managed internally). In such a case, it would be appropriate for the type of the property to be IEnumerable<Foo>. But that's hard to read. So instead of this:

public class SomeClass
{
    ...
    public IEnumerable<Foo> Foos
    {
        get { ... }
    }
}

I would rather see this:

public class SomeClass
{
    ...
    public Foo* Foos
    {
        get { ... }
    }
}

Of course, as you pointed out, Foo* is currently interpreted as pointer-to-Foo (at least in an unsafe context), which almost certainly precludes using that particular syntax. My overall point is that it would be nice to have some simplified syntax for representing IEnumerable<Foo> (perhaps Foo+).

I do lament the fact that "*" is already taken. The "*" character is used in many programming contexts to represent "0 to n" number of "things".
Java uses the elipse in a similar way to C#'s 'param's keyword to represent variable-parameter functions, Mathcad uses the semicolon, there's a whole load of unassigned punctuation that could be used.

But I''m weary of adding in too many language features, otherwise it becomes the anthesis of what the language was in the beginning; like how Firefox is now the bloated browser it. I propose C# adopts a 'modular' approach like XHTML or CSS (this would require a compiler rearchitecture though, but it would release it from inevitable bloat).

As for your problem, it reminds me of Delphi's support for indexer properties (similar to C#'s this[], but named).