Develop Reference

Can a method use an automatic variable to infer the return type?

IDictionary<int,string> myMethod()
{
var returnVal = ...;
return returnVal;
}
It seems like this is something that should be possible - create a var which automatically takes the method's return type - but I can't find any keyword which would match this. Does it exist?

Creating an object the way you're trying to will not work. A variable's type is determined when it is declared - the compiler doesn't care how you use it (for the most part). So, just because you return it doesn't mean the compiler will automatically infer what the initial type is.
Wjdavis15's answer (which has apparently now been deleted - it made use of generics and initializing the return value to default(T)) kinda sorta works, but it's very limited. It works fine for value types, but reference types the variable will be initialized to null... which is pretty useless unless you're planning on returning null to begin with. Instead, you might be able to do something like so:
private T MyMethod<T>() where T : new()
{
var retVal = new T();
...
return retVal;
}
// Use the method like so:
var dict = MyMethod<IDictionary<int,string>>();
This will work as long as T has a parameterless constructor. The problem with this, of course, is that the method is generic, meaning that it can be used with any class type, not just the one specific class you had in mind. You'd be better off using a non-generic method.
In summary, no, the feature you describe doesn't exist in C#. There are workarounds that are similar to what you want to do, but using them in the way you want is cumbersome and confusing, so it's better you just define what the variable is in the declaration.

If you call the method recursively then you can have a local variable that infers the type of that method's return value.
public static int Foo()
{
var bar = Foo();
return bar;
}
Of course, it forces you to call the method recursively to do so.

Using "value" as an identifier in C#

In writing short helper functions, I often find myself wanting to use the variable identifier "value" as an argument. It seems as though Visual Studio compiles this just fine, and has no complaints, when I do this:
public void MyMethod(int value, bool option, string message)
{
value = 1;
// More code...
}
However, Visual Studio complains at the following (as expected):
private int _myProperty;
public int MyProperty
{
get
{
return _myProperty;
}
set
{
int value = 0;
_myProperty = value;
}
}
This leads me to believe that "value" is treated as a keyword (or not) depending on the context. I am fairly new to C# and, as far as I know, I have not seen context-specific keywords in other languages.
The question:
Is it always safe to use "value" as a variable name outside of a property setter? If not, when can this be done safely? And, is this often considered bad practice?
I was surprised that I wasn't able to find this question already asked on SO, and I suspect that someone has asked it before. However, it is difficult to search for because so many posts have "variable" and "identifier" in the title. I was unable to find information about this on MSDN.
EDIT: The last question is meant to ask if it is often or commonly frowned upon. It has been changed to reflect this.

Here's what MSDN says:
The set accessor resembles a method whose return type is void. It uses an implicit parameter called value, whose type is the type of the property.
The properties are basically syntactic sugar that avoids you having to write a lot of get_Bar and set_Bar methods (note: there are some other advantages too, the CLR knows it's a property). For example, if you have a class like this:
public class Foo
{
private int _bar;
public int Bar
{
get { return _bar; }
set { _bar = value; }
}
}
It'll generate IL (for the setter) that looks something like this:
.method public hidebysig specialname
instance void set_Bar(int32 'value') cil managed
{
//
.maxstack 8
IL_0000: nop
IL_0001: ldarg.0
IL_0002: ldarg.1
IL_0003: stfld int32 Program/Foo::_bar
IL_0008: ret
} // end of method Foo::set_Bar
The thing to note here is that the set_Bar method takes a parameter called value. So not only does it "resemble" a method whose return type is void with a parameter called value, it actually is that.
So you can't use value for something else in a setter, obviously.
Now should you use it elsewhere? It depends. If it's obvious what it's referring to in the context where you are using it then sure. If value is ambiguous in a particular context then use something more explicit.
From MSDN:
The contextual keyword value is used in the set accessor in ordinary property declarations.
It makes no mention of any other context where value is considered a keyword, so aside from a setter, or anywhere else where it might have been defined already, you should be fine using value. Is it bad practice? Not as a rule, no more than any other potentially ambiguous variable name.
Edit: One place where I think having value as a name would be really problematic would be as a field (or worse a property) in a class. For example:
public class Foo
{
private int value;
public int Value
{
get { return value; }
set { value = value; } // which `value` are you setting? and to what?
}
}
Now you could remove the ambiguity here with this.value = value, but it still ugly and it seems better to me to just use a different name for you field.

In a property setter, the variable name value is reserved. It is used as the name of the variable which can be assigned to a backing field.
The question: Is it always safe to use "value" as a variable name outside of a property setter? If not, when can this be done safely? And, is this considered bad practice?
It's only reserved in the property setter. It's a very generic name, but it can often be the best description of the variable you are working with.
MSDN info

It is fine to use value as an identifier anywhere outside a set accessor. The C# Language Specification (linking old version) says:
Since a set accessor implicitly has a parameter named value,
it is a compile-time error for a local variable or constant
declaration in a set accessor to have that name.
The Word value is not (and was never) a full keyword in C#, even if it has had this special use in setters ever since C# 1.
See value (C# Reference) for more.
Of course, if you have a field (class-level variable) called value and you want to access it from within a set accessor, use this.value (or NameOfYourType.value for static fields).
For a list of real keywords and contextual "keywords", also see C# Keywords.

C# has lots of contextual keywords. The main reason for them in new versions of the language is to avoid breaking changes with existing compiling code. Contextual keywords lets them add new semantics, without breaking code that was previously valid.
As mentioned in Eric's article, you can always use # as a prefix to be able to use a keyword as an identifier. I think the main advantage of that is the ability to interoperate with other libs that may have been developed in other CLR language with a different set of keywords, where a C# keyword (either reserved or contextual) may not be a keyword in that other language.

As other have answered value is reserved for properties, however value it is not reserved specifically for methods, therefore, you can use value for variables everywhere other then properties setter
However if you set value in the get it will work just fine.
Good
public int MyProperty { get { int value = 0; return value; }}
Not good
public int MyProperty { get { ... } set { int value = 0; _MyProperty = value }}

C# has two types of keywords: global keywords and contextual keywords.
Global keywords may never be used as identifiers. Contextual keywords are reserved only in certain circumstances. For example, you may use most LINQ keywords as variable or method names, when the compiler sees that the code is not a query.
value is reserved only in property setters as the parameter name. Everywhere else you may use it as an identifier, and it often makes sense. I think it's unlikely that this keyword's context will expand, because a lot of programs use it as a parameter name and nobody likes breaking changes.

Passing a generic pointer to a method in c#

I have created a generic type to act as a pointer so that I can pass by reference. (Perhaps there is a much more simple way of doing this but I want to stress that I am doing this to learn more about generics and passing by reference, not the most efficient way of completing the task, if that makes sense.)
Here is the code I wrote for the generic type
class GenericPointer<T> {
public T item;
public void setItem(T i){ item = i; }
public T getItem(){ return item; }
}
In my program I have created an instance of this type called 'intPointer'. The value 143 is arbitrary.
GenericPointer<int> intPointer = new GenericPointer<int>();
intPointer.setItem(143);
Console.WriteLine(intPointer.getItem());
The above code runs properly, setting and returning the value 143.
I now want to pass this 'intPointer' to a method that increments it and then prints the value again.
So I wrote a method called addone()
public void addone(int i) { i ++; }
Now I want to make the following calls (remembering that I already set the value to 143):
Console.WriteLine(intPointer.getItem());
addone(intPointer);
Console.WriteLine(intPointer.getItem());
What I was expecting to see was 143 then 144 however I get the following errors:
The best overloaded method match for 'Notes.Program.addone(int)' has some invalid arguments
and:
cannot convert from 'Notes.GenericPointer<int>' to 'int'
Any help would be greatly appreciated!

I'll begin by correcting some of your terminology: you're not using pointers. C# does support pointers, but using the unsafe keyword, and they are real pointers (as in, integer memory addresses you can directly manipulate). The code you written is just an example of a boxed object.
.NET supports boxing already, by casting to Object; however it isn't recommended nor needed because the ref keyword solves the problem you're trying to "fix".
Use the ref keyword to describe a value-type parameter that should be passed by-reference instead of by-value. All other semantics remain the same, like so:
void Foo() {
int x = 123;
Bar(ref x);
Console.Write( x ); // prints "124".
}
void Bar(ref int x) {
x++;
}
I have a few other notes:
C# and .NET conventions dictate that all public members (methods, properties, fields, etc) should have TitleCase, not camelCase (i.e. ensure the first letter is capitalised).
Trivial getter and setter methods are discouraged, used Properties instead (though I note you cannot use ref arguments with properties).
You're getting your error because the type of intPointer is not int, but your class GenericPointer<int>.

While GenericPointer is wrapping an int, it is not actually an int so it cannot be treated as one. It has properties that are an int.
Imagine if GenericPointer wrapped a string. What would AddOne do to that.
You can act on the properties of the class but not treat the entire class as its generic type.
It would be possible to write an AddOne method that took a Generic Pointer argument and then inspected it for intyness and then added one to the internal item if it was an int. I am sure that is not a good idea.
What are you really trying to achieve with this GenericPointer?

If you want parameters to be reference if they are a value type (string, int, bool, etc.) then make your parameter like this:
public void addone(ref int i)
{
i++;
}
Then call the method like so:
addone(ref variableInt);
You can also look at this in order to see how to make your classes work as a specific type.

Showing warning when function result is not assigned to variable

I have a function that returns a modified copy of the object that was passed to this function. I often do something like this:
obj = obj.Foo(param);
Don't ask why, I simply have to. But sometimes, I (and others) forgot to assign the return value, doing this:
obj.Foo(param);
which repeatedly leads to time-consuming debugging.
Is there any way to show a warning or error every time when the function result is not assigned to a variable? Or any other suggestions on how to solve this issue?

You could use an out parameter, so the call would look like this:
obj.Foo(param, out obj);

You can use Resharper to assist with this issue; you need to decorate your method with the [Pure] attribute:
[Pure]
public static IList<T> RemoveItem<T>(this IEnumerable<T> thisList, T item)
{
var list = thisList.ToList();
list.Remove(item);
return list;
}
then when you call it without assigning the return value you will see:
The [Pure] attribute is defined in Resharpers Data Annotations: You need to copy the classes into your project so you can reference them (many very useful other annotations too)

It's totally legal and often desirable to not assign the return parameter so it would be wrong to have a warning for it. Henrik's answer to use an out parameter is what I'd recommend too to ensure the result is assigned everytime.

you can enable visual studio warings.
you can even customize the rule you want to apply.
you should see warnings in the case you don't assign the function to a variable
you can also decide to treat the waring as errors
Example:
public static class MyClass
{
public static string GetStr()
{
return "";
}
public static void Main()
{
GetStr();
}
}

I can't comment on answers, lacking stackoverflow credits. But I agree with Chris that it's totally legal and often desirable not to assign values returned from a method. It's also occasionally not desirable. e.g.
public static int Square(this int myValue)
{
return myValue * myValue;
}
It's clear that calling this method without assigning it is probably a bug. I think creating a code analysis rule that warned every time you didn't assign a value as Massimiliano suggested would be worse than not having the rule at all. In such cases it would be nice to be able to apply an attribute to the method...
[MustAssign]
public static int Square...
You could create a rule as Massimiliano suggested but only invoke the warning when the method is adorned with the attribute and the value returned from the method is not assigned. Not a trivial exercise though.

C# mimic overridding the assignment operator (=)

I've got a bit of a problem with a somewhat simple wrapper class I have.
It looks something like this:
public class Wrapper<T>
{
private T _value;
public Wrapper<T>(T value)
{
_value = value;
}
public static implicit operator Wrapper<T>(T value)
{
return new Wrapper<T>(value);
}
public static implicit operator T(Wrapper<T> value)
{
return value._value;
}
}
I've overriden the implicit converters from and to T, so it behaves almost like an instance of T itself.
e.g.
Wrapper<int> foo = 42;
However I've got a slight problem when assigning one instance of Wrapper to another, since I only want to assign the value of the second Wrapper class.
So right now, I have to do this:
Wrapper<int> foo = 42;
Wrapper<int> bar = (int)foo;
Or expose _value publicly through a property.
However since this is in a library, and I don't want the user to depend on remembering this, do you guys have any idea how I could mimic overridding the assignment operator ?
The problem in just changing the pointer (as it does when assigning a class instance to another), is that I've got a dictionary of pointers to these Wrapper objects, so I cannot have them changing all the time, since the dictionary would stop matching then.
I can see if this is somewhat confusing, so if I've left anything important out, please feel free to ask :-)

Since the assignment operator can't be overloaded, there isn't a real good solution. As somebody else pointed out, using a struct will give you the assignment semantics that you want, but then you're faced with value semantics--often not a good thing.
One option is to overload the constructor:
public Wrapper(Wrapper<T> w)
{
_value = w._value;
}
Which would result in this syntax:
Wrapper<int> foo = 42;
Wrapper<int> bar = new Wrapper<int>(foo);
Although more verbose than what you have, it reads better.
Or you could add a Clone method (not the ICloneable interface), so that you could write:
Wrapper<int> bar = foo.Clone();
You could get really creative and overload some operator, making it do essentially nothing. I wouldn't recommend that, though. Using operator overloading for those kinds of things typically makes code cryptic and often breaks.

You could make Wrapper<T> a struct. However I'm not sure if this would suit your application design or not.

If you look at Nullable<T>...which does a very similar thing to what you are doing here, it exposes the internal value using a .Value property.
The problem in just changing the pointer (as it does when assigning a class instance to another), is that I've got a dictionary of pointers to these Wrapper objects, so I cannot have them changing all the time, since the dictionary would stop matching then.
I'm not sure I follow this, what exactly are you storing in the dictionary? Because if you are storing references, the CLR will update them as necessary.

Don't implicitly cast your wrapper both ways.
public class DBValue<T>
{
public static implicit operator DBValue <T>(T value)
{
return new DBValue<T>(value);
}
public static explicit operator T(DBValue <T> dbValue)
{
return dbValue.Value;
}
private readonly T _value;
public T Value { get { this._value; } }
public DBValue(T value)
{
this._value = value;
}
}
Casting from DBValue<T> to T is a lossy conversion (as a minimum, you lose the fact that it's a value from the database), and by best-practice should be explicit. If you don't lose anything by casting from DBValue<T> to T, you might as well just use properties that return T.
Basically, you've already seen why you shouldn't be trying to do this: if a DBValue can be substituted for T and the other way around, how does the compiler (or developer) know which one to choose?
Requiring down-stream developers to write:
string value = MyProperty.Value
or
string value = (string)MyProperty
instead of
string value = MyProperty
...isn't all that onerous, and makes sure that everyone knows exactly what's going on.
EDIT:
To actually answer the question, you can't override reference assignment - or make it look like you have - but you shouldn't really need to.

This is what properties are for. They allow you to define what assignment means. You can't define it for a class or struct itself because they are already defined by the language to do necessary things. Just add a Value property to the class.
Alternatively, edit your question to give a broader description of your design and how this Wrapper fits into it, as someone may be able to suggest a simpler approach.

I just looked into it, making the class a struct is really not an option, since it has some logic in the parameterless constructor, plus it inherits an abstract class, which contains internal abstract functions.
I cannot use an interface, as that'd make those functions public, which would break the logic entirely.
I can post the entire class if that'd be helpful, but it's somewhat long (130 lines)
Or I could toss up on a seperate server, if that'd be better ? (though it hurts the integrity of this question, as I may delete it eventually from that server)
Also explaining the class is really difficult, without writing a complete essay :-/
Anyway I'll try to illustrate the problem I'm having.
Assume 2 table classes: CustomerTable and UserTable:
public class CustomerTable
{
Wrapper<string> Name;
}
public class UserTable
{
Wrapper<string> Name;
}
Now the problem is that some other developer, may use the above code as follows:
CustomerTable customer = new CustomerTable();
UserTable user = new UserTable();
user.Name = customer.Name; // This breaks my internal dictionary
What the developer should had done, in order for it to work, was:
user.Name = (string)customer.Name;
The problem is however, who in their right mind would think about that, when writing code ?
Even if I used a Value property, the developer would still have to remember to write
user.Name = customer.Name.Value; // or user.Name.Value = ....
And again the developer may forget this, and all of a sudden he gets exceptions, or worse: data which isn't persisted to the database.
So my issue is really, that I want the wrapper to be completely transparent (it should be usable as if it was in fact the class/primitive it's wrapping).
However when assigning from one wrapper to another, my internal logic breaks.
Phew a lot of writing, and a lot of code - let me know if I overdo the writing.

A J Lane I see what you mean, and I guess you're right - I just wanted to make it as simple as possible to use the library.
The reason for the implicit cast from DbValue to T, is to simply functions which expects T.
for example
literalSomething.Text = Server.HtmlEncode(SomeTable.SomeStringColumn);
rather than
literalSomething.Text = Server.HtmlEncode((string)SomeTable.SomeStringColumn);
This requires the cast to be implicit.
That being said I just read your comment whilst typing this, and I can see that's quite the issue.
I think I'll go back to exposing value through a property, it just requires the developer to type more, and kinda makes the code ugly I think.
Just imagine DbValue:
if (someValue.Value.HasValue) // someValue is DbValue<int?>
But then again it's probably better with "ugly" code, than code which behaves differently from what you'd expect by merely reading it.
I guess this question ends up as a "best practice" question really.
So to conclude, I'll create a Value property and use that instead of implicit casts, and the developer using the library will just have to live with that.
Thanks for your inputs :-)

This old post stills needs additional information to be complete. It's apparent that the original desired behavior cannot be accomplished since the = operator cannot be overloaded, and likewise C# cannot be "tricked" into casting an object to its own type... it will always boil down to a class reference assignment. But Steffen's further posts show the Wrapper class being used not just with local variables, but as a class field type. The desired semantics can be used AND the integrity of the internal dictionary maintained by using class properties instead of public fields.
Even keeping the original given Wrapper<T> class with both its implicit operators, here's code that would work:
public class CustomerTable
{
private Wrapper<string> _Name;
public Wrapper<string> Name {
get { return _Name; }
set { _Name = (string)value; }
}
}
public class UserTable
{
private Wrapper<string> _Name;
public Wrapper<string> Name {
get { return _Name; }
set { _Name = (string)value; }
}
}
If this change were made, it would not break existing code since it still allows various modes of setting the property:
CustomerTable customer = new CustomerTable();
UserTable user = new UserTable();
user.Name = customer.Name; //*** No longer breaks internal data structures
user.Name = "string literal"; // Works as expected with implicit cast operator
user.Name = (string)customer.Name; // Still allowed with explicit/implicit cast operator
user.Name = customer.Name.Value; // Also works if Value property is still defined
Because this still doesn't answer the original question, use of the Wrapper class could still be problematic if its used outside the class property context, i.e. passed between object, etc. Perhaps the entire Wrapper class could be eliminated with the proper class design, including use of property set/get accessors.