If I had to summarize the attractions of D in a sound bite, I might say it's like having the conveniences of C# with the simple running on the metal power of C.

With that in mind, I'm hoping that the next generation of C# features will find
their way into D at some point. If properly planned for, they could probably fit
right in without requiring any perling (@#$%#_[]!) or C++ing (*(foo)<<int>
>::->) of the syntax.

I apologize if everyone has already seen these but here are some interesting
links:
http://msdn.microsoft.com/vcsharp/future/
http://channel9.msdn.com/showpost.aspx?postid=114680 (watch the video)

The new features include (copied from their overview):

•	Implicitly typed local variables, which permit the type of local variables to
be inferred from the expressions used to initialize them.
•	Extension methods, which make it possible to extend existing types and
constructed types with additional methods.
•	Lambda expressions, an evolution of anonymous methods that provides improved
type inference and conversions to both delegate types and expression trees.
•	Object initializers, which ease construction and initialization of objects.
•	Anonymous types, which are tuple types automatically inferred and created from
object initializers.
•	Implicitly typed arrays, a form of array creation and initialization that
infers the element type of the array from an array initializer.
•	Query expressions, which provide a language integrated syntax for queries that
is similar to relational and hierarchical query languages such as SQL and
XQuery.
•	Expression trees, which permit lambda expressions to be represented as data
(expression trees) instead of as code (delegates).


Many of these features were added to support their LINQ (Language Integrated
Queries) technology that will be built right into the language. It allows you to
query and write to a wide variety of data sources (array variables, complex
in-memory structures, external files, relational databases, etc.) with a
consistent syntax that is part of the language itself. Here's an example of
querying an int array:
=============
public void Linq1()
{
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

var lowNums =
from n in numbers
where n < 5
select n;

Console.WriteLine("Numbers < 5:");
foreach (var x in lowNums)
{
Console.WriteLine(x);
}
}

===========

You could then easily evolve it to query an external data source--disk file, XML doc via HTTP, relational database, etc. without changing the query or any processing done with the results of the query.

This works because the "var" is a new data type indicator that tells the compiler to figure out the type for itself (meaning therefore at compile time, not runtime). If you say var x = int[]{1,3,5}, x becomes an array of int for the rest of its life. If you say var x = customer.getField("Name"), x becomes a String. It's not dynamically typed, like a scripting language, where the type is inferred at runtime. It is still statically typed, like D, but the compiler infers the type at first initialization and enforces it thereafter.

I also like the notion of "anonymous types":

var hammer = new { name = "Hammer", price = 15.00 };
var saw = new { name = "Saw", price = 12.95 };
var tool = hammer;

Then you could change the price of "tool" with "tool.price = 14.95".
I think (not sure) that you could then also reassign "tool" to point at any
object that had attributes "name" and "price", regardless of the other details
about its type. It would only be aware of those two attributes/members as it
would be a variable of type <anything containing a String member called "name"
and a double member called "price">).

These more dynamic, but still compile time, techniques allow you to let your code adjust itself to evolving data structures so you can have the easily evolvable code of a scripting language without sacrificing the type safety or performance obtainable with static typing. (OCaml does this and gets great performance. D could probably do it even faster.)

Check out some other code snippets here: http://msdn.microsoft.com/vcsharp/future/linqsamples/

It is clear that Walter has been paying attention to C#, to the benefit of D, and I hope that he will continue with these new goodies in C# 3, even if they have to wait for a later version of D. (At least reserve room for them in D's syntax space.) I suspect that D would have an easier time including these features than most other languages, and I also suspect that these features would prove very popular. (I know they would with me.)

Glen Perkins wrote:
> 
> The new features include (copied from their overview):
> 
> •	Implicitly typed local variables, which permit the type of local variables to
> be inferred from the expressions used to initialize them.

D allready has it and it is calles auto not var.

> •	Extension methods, which make it possible to extend existing types and
> constructed types with additional methods.

D has it for array types, but could probbably be possible to extend to other types

> •	Lambda expressions, an evolution of anonymous methods that provides improved
> type inference and conversions to both delegate types and expression trees.
> •	Object initializers, which ease construction and initialization of objects.
> •	Anonymous types, which are tuple types automatically inferred and created from
> object initializers.
> •	Implicitly typed arrays, a form of array creation and initialization that
> infers the element type of the array from an array initializer.

I don't see much difference between Implicitly typed local variables so D has it.

> •	Query expressions, which provide a language integrated syntax for queries that
> is similar to relational and hierarchical query languages such as SQL and
> XQuery.
> •	Expression trees, which permit lambda expressions to be represented as data
> (expression trees) instead of as code (delegates).
> 

As for other things I must agree that some of them would fiz nicely into D sytax.

Glen Perkins wrote:
> http://channel9.msdn.com/showpost.aspx?postid=114680 (watch the video)

Ouch! Bill is invading my head, whadda ma gonna do?

Nice video. Cool stuff, too.

Damn, it almost made me want to move to Redmond, they seemed to have such a good time doing interesting stuff. At the end I was in a good mood, smiling, and felt that I'd actually been in the room with the guys. I feel like I've actually met Hejlsberg!

Sigh.

> D has it for array types, but could probbably be possible to extend to other types

This would be awesome !  Maybe if we all ask Walter for it we can get him to include it for all types.  Just for clarification the function:

char [] strip_tags( char []  ) { ... }

can currently be called like

<code>

char [] html;

char [] buf = html.strip_tags();
-- or
char [] buf = strip_tags(html );

</code>

But only works for arrays ( of any type ).

> > • Query expressions, which provide a language integrated syntax for
queries that
> > is similar to relational and hierarchical query languages such as SQL
and
> > XQuery.

It'll be interesting to see how this comes out, and if they can really pull it off :).

Some pretty radical ideas.

Charlie



"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dmbtbf$2j92$1@digitaldaemon.com...
> Glen Perkins wrote:
> >
> > The new features include (copied from their overview):
> >
> > • Implicitly typed local variables, which permit the type of local
variables to
> > be inferred from the expressions used to initialize them.
>
> D allready has it and it is calles auto not var.
>
> > • Extension methods, which make it possible to extend existing types and constructed types with additional methods.
>
> D has it for array types, but could probbably be possible to extend to other types
>
> > • Lambda expressions, an evolution of anonymous methods that provides
improved
> > type inference and conversions to both delegate types and expression
trees.
> > • Object initializers, which ease construction and initialization of
objects.
> > • Anonymous types, which are tuple types automatically inferred and
created from
> > object initializers.
> > • Implicitly typed arrays, a form of array creation and initialization
that
> > infers the element type of the array from an array initializer.
>
> I don't see much difference between Implicitly typed local variables so D has it.
>
> > • Query expressions, which provide a language integrated syntax for
queries that
> > is similar to relational and hierarchical query languages such as SQL
and
> > XQuery.
> > • Expression trees, which permit lambda expressions to be represented as
data
> > (expression trees) instead of as code (delegates).
> >
>
> As for other things I must agree that some of them would fiz nicely into D sytax.

I just want to see D 1.0 :)

Charles wrote:
>>D has it for array types, but could probbably be possible to extend to
>>other types
> 
> 
> This would be awesome !  Maybe if we all ask Walter for it we can get him to
> include it for all types.  Just for clarification the function:
> 
> char [] strip_tags( char []  ) { ... }
> 
> can currently be called like
> 
> <code>
> 
> char [] html;
> 
> char [] buf = html.strip_tags();
> -- or
> char [] buf = strip_tags(html );
> 
> </code>
> 
> But only works for arrays ( of any type ).
> 

I would like to here the official opinion on this feature because i don't think it is even documented, and that might mean this feature is not intended but only a bug in the current implementation. It would IMO be great if it really was a feature and extended to all types.

Ivan Senji wrote:
> Charles wrote:
> 
>>> D has it for array types, but could probbably be possible to extend to
>>> other types
>>
>>
>>
>> This would be awesome !  Maybe if we all ask Walter for it we can get him to
>> include it for all types.  Just for clarification the function:
>>
>> char [] strip_tags( char []  ) { ... }
>>
>> can currently be called like
>>
>> <code>
>>
>> char [] html;
>>
>> char [] buf = html.strip_tags();
>> -- or
>> char [] buf = strip_tags(html );
>>
>> </code>
>>
>> But only works for arrays ( of any type ).
>>
> 
> I would like to here the official opinion on this feature because i don't think it is even documented, and that might mean this feature is not intended but only a bug in the current implementation. It would IMO be great if it really was a feature and extended to all types.

I believe it was an accidental feature that quickly became accepted as useful when it was discovered.  It's been discussed in this group several times before.

-JJR

John Reimer wrote:
> Ivan Senji wrote:
>>
>> I would like to here the official opinion on this feature because i don't think it is even documented, and that might mean this feature is not intended but only a bug in the current implementation. It would IMO be great if it really was a feature and extended to all types.
> 
> 
> I believe it was an accidental feature that quickly became accepted as useful when it was discovered.  It's been discussed in this group several times before.
> 

Yes i know, but Walter never participated in any of those discussions.

I had a couple thoughts along this vain.

First, IIRC Walter has said the that array property trick is NOT a bug, just un-documented.

Second, properties can be defined for classes, structs and to some extent arrays, why not for typedefs? Besides the advantages that are present for classes and structs, some other advantages come to mind. This would allow for things like range checking.

Third, a delegate can be defined using a method call on a class or struct or a nested function call. All of these amount to a pairing of a function pointer with its first argument. Why not allow the same syntax to be used for a property call with an array? Or for that matter, if properties are allowed on non arrays, how about allow a delegate to be made from any property call? Thus the following would be allowed:

char[] array = "this is a test\n\0junk";
int i, j;

i = array.fn();	// works

int delegate() dg = &array.fn;
j = dg();

..

int fn(char[] c)
{
for(int i=0;i<c.length;i++)
if(c[i] == '\0') return i;
}




In article <dmcrn4$b4f$1@digitaldaemon.com>, Charles says...
>
>> D has it for array types, but could probbably be possible to extend to other types
>
>This would be awesome !  Maybe if we all ask Walter for it we can get him to include it for all types.  Just for clarification the function:
>
>char [] strip_tags( char []  ) { ... }
>
>can currently be called like
>
><code>
>
>char [] html;
>
>char [] buf = html.strip_tags();
>-- or
>char [] buf = strip_tags(html );
>
></code>
>
>But only works for arrays ( of any type ).
>

clayasaurus wrote:
> I just want to see D 1.0 :)
> 
I agree! There will always be more new ideas to take on board, but I think finishing implementing the great list of features that D already has ironing out the issues with those has got to be more important, otherwise D just ends up being an experimental melting pot and never gets to a point where it's "finished". I think you need some stable definition of the language to get it widely used. Let's polish what we've got, rather than continually add bells and whistles.

Just my tuppence

Munch