Could we please get a __forceinline for the compiler allowing us to make decisions at compile time to help us with optimisation.
I know that the long term and "correct" answer is to put this sort of thing in the Jit but in the short term can we please be treated like grownups and get some way of telling the compiler that this property or method really really should be inlined. I would even go for adding an attribute to functions where I want everything to be inlined inside i.e. [InlineEverything(MyNamespace)] Void Foo() { MyClass a = new MyClass(); MyClass b = new MyClass(); MyClass c = a + b; Console.WriteLine( "C = {0}", c.ToString() ); } This would inline the constructor for MyClass, the operator+ for MyClass and the ToString, but leave intact the call to Console.WriteLine. And to go one step further, control over the level of inlining would be good to, i.e. default level is 1 so only the immediate function would be inlined, 2 would inline up to 2 calls deep, -1 would inline everything. This would greatly enhance optimising of things like Maths intensive operations Regards Russell -----Original Message----- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Scott Peterson Sent: 04 February 2009 09:57 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] gmcs and The Future Generic type variance has landed in gmcs SVN [1]. This is a C# 4 feature. It can be enabled by passing -langversion:future. While type variance is cool, I want to talk about -langversion:future. I see this as being a sentinel langversion for features as yet unreleased by Microsoft. Those features could be announced additions to the language (as with generic type variance, or the "dynamic" keyword) but they need not be. Mcs has done an excellent job of tracking the official C# language, and it will continue to do so, but the Mono project has a world-class compiler entirely at its disposal. We need not confine ourselves to the blessed specs of Microsoft or Ecma. We could "trick out" C#, indulging in sugars of our own device, so long as we keep our creations in -langversion:future. Those projects which are willing to sacrifice compatibility with csc in order to partake of our forbidden fruit can write code in this New C#. This C#++. This -langversion:future. To be clear, I am not advocating VM changes. Anything to come out of this compiler would remain binary-compatible with the .NET runtime. Language features and APIs only. I have loads of ideas - I actually keep a list where I jot down every language feature idea I come up with - but I want to hear from the list. Do you like the idea? Do you have concerns? Do you have a language feature you've always wanted? I will start the ball rolling with a simple feature: Problem: While the 'typeof' keyword is very convenient for getting Type objects, it is much more difficult to get any other kind of reflection data. For example, to get a MethodInfo object, one usually does: > static readonly MethodInfo methodInfo = typeof(Foo).GetMethod("Bar", new Type [] { typeof(string), typeof(int) }); Not only is this an eyesore, but we have a method name in a string. If I refactor that method, I will have to remember to update this code as well. Solution: The "reflect" keyword. This is like the typeof keyword, but you can use it to reflect upon anything. Examples: > Type fooType = reflect(Foo); > MethodInfo barMethod1 = reflect(Foo.Bar(string)); > MethodInfo barMethod2 = reflect(Foo.Bar(string,int)); > FieldInfo batField = reflect(Foo.bat); > PropertyInfo bazProperty = reflect(Foo.Baz); > ConstructorInfo fooCtor1 = reflect(new Foo()); > ConstructorInfo fooCtor2 = reflect(new Foo(string)); > ConstructorInfo staticFooCtor = reflect(static Foo()); > EventInfo fooEvent = reflect(Foo.Changed); And if I refactor any of these members or types, my IDE will update this code as well. Your turn. - scottp [1] http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ____________________________________________________________________ This email has been scanned by the MessageLabs Email Security System ____________________________________________________________________ DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list