A: 

It's quite simple actually. As the Method seems to have another responsibility than your current Class (why else would you hide this method) move your method into it's own Class and the part you want to have private into a private method in the new class.

dbemerlin
"You have this small delegate problem with the compiler, so you should change your design entirely."
zneak
Moving a method that has nothing to do with the current class into it's own class is actually good design and not that big of a change. Trying to force a solution without rethinking the approach is the worse decision.
dbemerlin
How can you infer so much information about a method and a class you know nothing about? I don't think you need to question OP's design validity for such a simple question about a compiler feature.
zneak
Who said that the method has nothing to do with the current class? Perhaps the class level is too general. One-off stuff is one of the biggest benefits of anonymous methods when having a class level method is overkill.
Davy8
If he wants to hide something from the current class it can't belong there so it requires it's own class. Ofc i don't know all the details but to me it looks very much like he is afraid of adding another class and instead adds more complexity by using nested methods (or at least something that behaves similarly). Anyways, everyone is entitled to his own opinion, if he wants complex, he can use complex, thats the good thing about C#.
dbemerlin
Davy8 and dbemerlin are correct. Making another (even nested) class is both overkill and leaks data to a wider scope than it has a right to be in. To the other commenters: when it's more complex I agree that moving it to it's own class is (better) good design that what I'm after, but in some cases it is also objectual over kill.
TerryP
I don't think hiding something from the class justifies another class (that's the whole point of, you know, local variables), and I find it interesting that you find classes are simpler than delegates.
zneak
+8  A: 

You actually can do this in C#.

Func<T1, T2, ..., TReturn> myFunc = (a, b, ...) =>
{
  //code that return type TReturn
};


If you need an anonymous method of return type void use Action instead of Func:

Action<T1, T2, ...> myAction = (a, b, ...) =>
{
  //code that doesn't return anything
};
Lasse Dahl Ebert
+1 http://en.wikipedia.org/wiki/Closure_(computer_science)
Tim Robinson
+4  A: 

If you explicitly type it, it will work, i.e.

Action<paramType1, paramType2> helperAction = (/* parameter names */) => { /* code to encapsulate */ };
Func<paramType1, paramType2, returnType> helperFunction = (/* parameter names */) => { /* code to encapsulate */ };

The reason var doesn't work is that a lambda expression can evaluate to multiple types (I believe either a delegate or expression tree, but don't quote me on that) and the compiler in this situation is unable to infer which was meant.

Davy8
Sounds plausible enough for why var fails with a lambda expression, but the older delegate(){} syntax should be easily inferred by the compiler, e.g. var x = delegate() { return constantexpr }; is also an error. Maybe it is just a case of "Sorry, not done yet... maybe in C# 6.0 folks!" :-S.
TerryP
+5  A: 

If you are in C# 3.5 or higher you can take advantage of the lambdas and convenience delegate declarations Func<> and Action<>. So for instance

void DoSomething()
{
  Func<int,int> addOne = (ii) => ii +1;
  var two = addOne(1);
}

The reason you can't do

var addOne = (ii) => ii +1;

is because of Homoiconicity, the lambda can be interpreted as two different constructs, a delegate and an expression tree. Thus the need to be explicit in declaration.

Scott Weinstein
Accepted as answer among your peers, because it notes "3.5 or higher", which is useful for the sake of anyone else stumbling across this question via search.
TerryP
for all intent and purposes you're right but strictly speaking (or when looking at the IL) it's a fancy way of declaring a class field, store a delegate in it and call that, so when looking at the IL it's not hidded (obscured by the name but not hidden)
Rune FS
Btw: In C#2.0 the trick would be to use an anonymous delegate instead a Lambda expression
Rune FS
+1  A: 

You can't use the var keyword with lambdas or delegates because they both require additional context information (delegates require a return type, and lambdas require a return type and parameter types). For instance, the (params) => { code } syntax requires to be able to infer the parameter types and return types to work: you do this by explicitly giving it a type.

The generic System.Action delegate type (returns void) could do a good job at what you're trying:

Action<ArgumentType1, ArgumentType2, ...> myDelegate = (params) => { code };

Otherwise, there's also the System.Func, which has a return type, that must be passed as the last generic argument.

zneak
+2  A: 

I recommend looking at the Action<T> and Func<TResult> delegates and their overloads. You can do something like this

static void Main(string[] args)
{
    SomeMethod();
}

private static void SomeMethod()
{
    Action<int> action = (num) => Console.WriteLine(num);

    Enumerable.Range(1,10).ToList().ForEach(action);

    Console.ReadKey();
} 

Here SomeMethod is private and has a local Action<int> delgate that takes an int and does something to it.

I think the issue that you came across is that you can't use implicit typing (i.e. use var) when assigning a lambda expression to a variable.

Russ Cam
A: 

It depends on what your definition of hiding is.

The func/action solution (like the one Scott suggests)

void DoSomething()
{
  Func<int,int> addOne = (ii) => ii +1;
  var two = addOne(1);
}

Feals like hidding the method definition when writing regular C# code BUT is when looking at the IL equivalent of

//This is pseudo code but comes close at the important parts
public class Class1
    {
        //The actual type is different from this
        private static Func<int, int> myMethod = AnonymousFunction; 

        public void f()
        {
            myMethod(0);
        }

        private static int AnonymousFunction(int i)
        {
            return 1;
        }
    }

So if you really want to get to the method from outside of the one "hidding" it you can do this with reflection The actual name generated for the field storing the delegate is illegal in C# bul valid in CLR context but that's the only thing that stand in the way of using the delegate as a regular delegate stored in a field (that is if you figue out the name :) )

Rune FS