digitalmars.D - Why is the "in" storage class missing from the ParameterStorageClass enum?
- Andrej Mitrovic (13/13) Jan 20 2011 import std.stdio;
- Jonathan M Davis (4/28) Jan 20 2011 Umm. in is never the default. in is essentially an alias for const scope...
- Andrej Mitrovic (6/10) Jan 20 2011 That's what I thought. But I did saw it mentioned in this NG a couple
- Lutger Blijdestijn (3/17) Jan 20 2011 It's not needed because it should resolve to SCOPE for ParameterStorageC...
- Christopher Nicholson-Sauls (4/18) Jan 22 2011 It's possible someone was talking about D1 where 'in' meant something
import std.stdio; import std.traits; alias ParameterStorageClassTuple STCTuple; alias ParameterStorageClass STC; void foo(in int[] x) { /*x[0] = 5; // This would be a compile-time error*/ } void bar(int[] x) { x[0] = 5; } void main() { assert(STCTuple!foo[0] == STC.NONE); assert(STCTuple!bar[0] == STC.NONE); } Someone said that "in" was the default storage class when there is no storage class specified for a parameter. But if that is true then how come bar can modify the contents of the x parameter? If parameters really have "in" as the default storage class, bar's function body would be a compile time error, just like foo's is if you uncomment its code. (Yes, I know a fat pointer is passed in with both functions. But "in" is supposed to give some guarantees as to what you can do with a parameter.) So, which part of this am I misunderstanding here?
Jan 20 2011
On Thursday, January 20, 2011 19:03:09 Andrej Mitrovic wrote:import std.stdio; import std.traits; alias ParameterStorageClassTuple STCTuple; alias ParameterStorageClass STC; void foo(in int[] x) { /*x[0] = 5; // This would be a compile-time error*/ } void bar(int[] x) { x[0] = 5; } void main() { assert(STCTuple!foo[0] == STC.NONE); assert(STCTuple!bar[0] == STC.NONE); } Someone said that "in" was the default storage class when there is no storage class specified for a parameter. But if that is true then how come bar can modify the contents of the x parameter? If parameters really have "in" as the default storage class, bar's function body would be a compile time error, just like foo's is if you uncomment its code. (Yes, I know a fat pointer is passed in with both functions. But "in" is supposed to give some guarantees as to what you can do with a parameter.) So, which part of this am I misunderstanding here?Umm. in is never the default. in is essentially an alias for const scope. The default is non-shared and mutable. - Jonathan M Davis
Jan 20 2011
On 1/21/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:Umm. in is never the default. in is essentially an alias for const scope. The default is non-shared and mutable. - Jonathan M DavisThat's what I thought. But I did saw it mentioned in this NG a couple of times, I can't remember by who though. In any case, "in" seems to be missing from that enum definition. So unless there's a specific reason for its absence, I'd file an enhancement request.
Jan 20 2011
Andrej Mitrovic wrote:On 1/21/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:It's not needed because it should resolve to SCOPE for ParameterStorageClass and const is not a storage class, but a type constructor.Umm. in is never the default. in is essentially an alias for const scope. The default is non-shared and mutable. - Jonathan M DavisThat's what I thought. But I did saw it mentioned in this NG a couple of times, I can't remember by who though. In any case, "in" seems to be missing from that enum definition. So unless there's a specific reason for its absence, I'd file an enhancement request.
Jan 20 2011
On 01/20/11 21:57, Andrej Mitrovic wrote:On 1/21/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:It's possible someone was talking about D1 where 'in' meant something very different, and was in fact the default. -- Chris N-SUmm. in is never the default. in is essentially an alias for const scope. The default is non-shared and mutable. - Jonathan M DavisThat's what I thought. But I did saw it mentioned in this NG a couple of times, I can't remember by who though. In any case, "in" seems to be missing from that enum definition. So unless there's a specific reason for its absence, I'd file an enhancement request.
Jan 22 2011