Idea for an implicit context sensitive statement. (period) as syntactic sugar

Question

Some C # operations seem unnecessarily cumbersome compared to other languages. For example lambdas:

students.GroupBy(student => student.State).Where(student => student.Count > 1).OrderByReversed(studentGroup => studentGroup.Count); 

This can be shortened by using very short variable names:

 students.GroupBy(s => s.State).Where(s => s.Count > 1).OrderByReversed(sg => sg.Count); 

But in this way, variables are hard to understand out of context. Another way to shorten it is to simply skip the one-parameter listing completely, and the parameter should be implied by a dot:

 students.GroupBy(.State).Where(.Count > 1).OrderByReversed(.Count); 

For me it is a little readable than any of the above. This applies only to one-parameter lambdas, and, of course, this value is inferred from the context.

Edit: for lambdas where the parameter itself is used directly. 'can be used as a direct placeholder:

 var lines = text.Split("\n").Where(line => line != ""); 

You can reduce it a bit using:

 var lines = text.Split("\n").Where(. != ""); 

Another place this type of affiliate operator can use is in the Enum transmission. Often the enumeration name is passed too much when it is obvious from the context that it is. For example, working with OpenTK (implementation of OpenGL in C #), to create simple textures you need to call something like this every time:

 GL.TexImage2D(TextureTarget.Texture2D, 0, PixelInternalFormat.Rgba, bd.Width, bd.Height, 0, OpenTK.Graphics.OpenGL.PixelFormat.Bgr, PixelType.UnsignedByte, myPointer); GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMinFilter, (int)TextureMinFilter.Linear); GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMagFilter, (int)TextureMagFilter.Linear); 

(Note that OpenTK.Graphics.OpenGL.PixelFormat must be passed with a full name, as it conflicts with System.Drawing.Imaging.PixelFormat using dot notation, this is no longer necessary)

This contains many enum enums, which in an equivalent C ++ implementation are much shorter and therefore easier to read at a glance. We could try to skip the names of the enumerations and get them out of context (parameter type of the called method):

 GL.TexImage2D(.Texture2D, 0, .Rgba, bd.Width, bd.Height, 0, .Bgr, .UnsignedByte, myPointer); GL.TexParameter(.Texture2D, .TextureMinFilter, (int).Linear); GL.TexParameter(.Texture2D, .TextureMagFilter, (int).Linear); 

This is not only short, but also shorter than the equivalent of C ++, which is easy to read, preserving the strongly typed character of the language. I am sure that there are other places where it can be used, these are just some syntax examples that I would like to see in the next version of C #. Do you think this would be a good idea?

Answer 1

As for your first example, suppose we see

 (x,y) => .z + .q; 

Is z member of x or y ? What if both x and y have a member called z ?

Answer 2

Not sure how much this is a question, but I will try to put my two cents.

The only feature I missed from VB is the [With][1] operator. This can certainly lead to terrible mess (just imagine what the nested With do), but it retained a few keystrokes and also made the code more visually explicit (in the sense that "here I set the properties of the SqlConnection object"). Then came Object Inicializers in C # 3, a similar (and more advanced) function, and they are usually sufficient for most With scenarios.

The C # team did a great job of keeping developers focused on what instead of how , removing redundant syntax everywhere. "lambda" existed in C # 2, only they were called anonymous delegates, and their syntax was something like this:

 itemTypes.Find(delegate(ItemType itemType) { return itemType.Name == typeName; }); 

which in C # 3 has been reduced to

 itemTypes.Find(itemType => itemType.Name == typeName); 

This is just one example of how simplifying the syntax was simpler and more understandable, and this increased the visibility of this function. I don’t know many developers who used or even knew how to use anonymous delegates, but now he expected that any C # developer worthy of its salt should be convenient with lambdas.

Now, looking at your proposed functions, give the pros and cons a lot (from the point of view of the developer, not from the point of view of language design):

Pro:

• Syntax brevity
• Increased ease of use in most use cases
• Implicit gain => It’s easier to train new students in the dark art, which is C #

Con (lambdas):

• Confusion in two or more parameters (this can be solved by assuming that it is illegal for two parameter methods)
• Confusion in nested lambdas (this is the same problem with nested With - it's just bad practice)

Con (enumerations):

• Enums are not really strongly typed, so this might explode in some scenarios (this is just a feeling, has no example)

---

On the bottom line, I would like to see this function in the case of lambda, but in the case of enumerations this is a little bit.

The Bottomer line, I don’t think there is a real usefulness to this function to justify a change in syntax, so it probably will not be implemented soon (if ever). Tuples and continuation properties are still my favorite non-existent C # features.