Re: static functions?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, March 11, 2024 10:51:48 AM MDT Andy Valencia via Digitalmars-d-
learn wrote:
> On Monday, 11 March 2024 at 16:25:13 UTC, Jonathan M Davis wrote:
> > ...
> > But what exactly static means varies based on the context.
>
> Thank you for the list!  But none of those appear to apply to a
> function defined in the outermost scope of the module.  Is static
> accepted here--but has no actual effect?

There are a number of cases where D allows you to use attributes that are
then ignored when they're used on a symbol where they don't make sense. It's
particularly useful when using the : syntax, since then you can apply an
attribute to the file as a whole without getting a bunch of errors about
that attribute not applying to some of the symbols within the module, but it
does have the downside of making it less obvious when an attribute is
ignored.

> I will look at the privacy controls--thanks again.

Yes, that's what you want if you want to control which symbols are visible
outside the module.

- Jonathan M Davis

Re: static functions?

[user1234 via Digitalmars-d-learn]

On Monday, 11 March 2024 at 16:51:48 UTC, Andy Valencia wrote:
On Monday, 11 March 2024 at 16:25:13 UTC, Jonathan M Davis 
wrote:

...
But what exactly static means varies based on the context.


Thank you for the list!  But none of those appear to apply to a 
function defined in the outermost scope of the module.  Is 
static accepted here--but has no actual effect?


Yes module-level `static` (for what is aka "free-functions", but 
also variables) is a noop. Module-level is implicitly static.



I will look at the privacy controls--thanks again.


No need to ;) D `static` is a storage class, not a visibility 
attribute.



Andy

Re: static functions?

[Andy Valencia via Digitalmars-d-learn]

On Monday, 11 March 2024 at 16:25:13 UTC, Jonathan M Davis wrote:

...
But what exactly static means varies based on the context.


Thank you for the list!  But none of those appear to apply to a 
function defined in the outermost scope of the module.  Is static 
accepted here--but has no actual effect?


I will look at the privacy controls--thanks again.

Andy

Re: static functions?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, March 11, 2024 9:56:24 AM MDT Andy Valencia via Digitalmars-d-learn 
wrote:
> Leveraging my knowledge of C, I assumed a "static" function would
> be hidden outside of its own source file.  I can't find any
> statement about the semantics of a static function in the
> documentation, and in practice (ldc2 on Linux) it doesn't hide
> the function?

No, static does nothing of the sort in D. You can read the documentation
here:

https://dlang.org/spec/attribute.html#static

But what exactly static means varies based on the context.

For module constructors and destructors, it means that that constructor or
destructor runs once for the entire program, whereas otherwise, they would
run once per thread.

For member functions (i.e. functions on structs or classes), it means that
the function has no this reference. So, it's a function on the struct/class
itself and not associated with an instance of the struct/class, whereas
non-static member functions must be called on an instance of that struct or
class.

For nested functions, it means that the function does not have access to
variables inside the function that it's nested in (whereas a non-static
member function has access the symbols in the function that it's declared
in).

For member variables (that is, variables on a struct or class), it makes it
so that there is only one instance of that variable for that struct or class
per thread rather than one per instance of the struct or class.

For variables within a function, it makes it so that there is only one
instance of that variable per thread (as opposed to the variable only
existing for the duration of a specific function call).

For nested structs or classes, it means that they don't have access to their
outer scope (generally either the function that they're declared in or the
class or struct that they're declared in).

I'm probably missing some other uses of static, but those are the ones that
come to mind at the moment.

Aside from module constructors and destructors, I can't think of any case
off the top of my head where static does anything at module scope. So,
putting static on a function at module scope (rather than within a struct or
class) does nothing.

If you want to control the visibility of any symbol within a module, then
you need to use the visibility attributes:

https://dlang.org/spec/attribute.html#visibility_attributes

And specifically, to make a symbol only be visible inside a module, you
mark it with private.

- Jonathan M Davis

static functions?

[Andy Valencia via Digitalmars-d-learn]

Leveraging my knowledge of C, I assumed a "static" function would 
be hidden outside of its own source file.  I can't find any 
statement about the semantics of a static function in the 
documentation, and in practice (ldc2 on Linux) it doesn't hide 
the function?



file tst.d:

import std.stdio : writeln;
import tst1;

void
main()
{
writeln(do_op());
writeln(do_op());
}


and file tst1.d:

static int
do_op()
{
static int x;

x += 1;
return(x);
}

Re: C style 'static' functions

[Johannes Pfau via Digitalmars-d-learn]

Am Wed, 19 Jul 2017 19:18:03 +
schrieb Petar Kirov [ZombineDev] :

> On Wednesday, 19 July 2017 at 18:49:32 UTC, Johannes Pfau wrote:
> >
> > Can you explain why _object-level visibility_ would matter in 
> > this case?  
> 
> (I'm sure you have more experience with shared libraries than me, 
> so correct me if I'm wrong)
> 
> We can't do attribute inference for exported functions because 
> changing the function body may easily change the function 
> signature (-> name mangling) and break clients of the (shared) 
> library. Therefore, it follows that attribute inference can only 
> be done for non-exported functions.

OK, I didn't think of the stable ABI argument, that indeed does make
sense. Leads to the strange consequence though that private functions
called from templates need to be exported and therefore can't use
inference.

OT: if a function private function is exported and called from a public
template things are difficult either way. Such a function needs to be
considered to be 'logically' public: As the template code instantiated
in another library will not get updated when you update the library
with the private function, you also have to ensure that the program
logic is still valid when mixing a new implementation of the private
function and an old implementation of the template function

-- Johannes

Re: C style 'static' functions

[via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 18:49:32 UTC, Johannes Pfau wrote:


Can you explain why _object-level visibility_ would matter in 
this case?


(I'm sure you have more experience with shared libraries than me, 
so correct me if I'm wrong)


We can't do attribute inference for exported functions because 
changing the function body may easily change the function 
signature (-> name mangling) and break clients of the (shared) 
library. Therefore, it follows that attribute inference can only 
be done for non-exported functions.

Re: C style 'static' functions

[Johannes Pfau via Digitalmars-d-learn]

Am Wed, 19 Jul 2017 17:37:48 +
schrieb Kagamin <s...@here.lot>:

> On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer 
> wrote:
> > I'm not so sure of that. Private functions still generate 
> > symbols. I think in C, there is no symbol (at least in the 
> > object file) for static functions or variables.  
> 
> They generate hidden symbols. That's just how it implements 
> private functions in C: you can't do anything else without 
> mangling.

This is not entirely correct. The symbols are local symbols in elf
terminology, so local to an object file. Hidden symbols are local to an
executable or shared library.

> You probably can't compile two C units into one object 
> file if they have static functions with the same name - this 
> would require mangling to make two symbols different.

1) C does have mangling for static variables:
void foo() {static int x;}
==> .local  x.1796

2)
Object file? No, but you cant compile two translation units into one
object file anyway or declare two functions with the same name in one
translation file.
For executables and libraries, ELF takes care of this. One major usecase
of static functions is not polluting the global namespace.

---
static int foo(int a, int b)
{
return a + b + 42;
}

int bar(int a, int b)
{
return foo(a, b);
}
---
nm =>
0017 T bar
 t foo

---
static int foo(int a, int b)
{
return -42;
}

int bar(int a, int b);

int main()
{
return bar(1, 2);
}
---
nm =>
 U bar
 t foo
 U _GLOBAL_OFFSET_TABLE_
0011 T main

nm a.out | grep foo =>
063a t foo
0670 t foo

Additionally, when compiling with optimizations both foos are gone: All
calls are inlined, the functions are never referenced and therefore
removed. This can reduce executable size a lot if you have many local
helper functions, so D may benefit from this optimization as well.


-- Johannes

Re: C style 'static' functions

[Johannes Pfau via Digitalmars-d-learn]

Am Wed, 19 Jul 2017 17:25:18 +
schrieb Petar Kirov [ZombineDev] <petar.p.ki...@gmail.com>:


> >
> > Note: not 100% sure of all this, but this is always the way 
> > I've looked at it.  
> 
> You're probably right about the current implementation, but I was 
> talking about the intended semantics. I believe that with DIP45, 
> only functions and global variables annotated with the export 
> storage class would necessary have externally visible symbols.
> 

Yes, this DIP is the solution to have true C-like static functions.
Non-exported private will then be equivalent to C static.

> Also, consider this enhancement request (which I think Walter and 
> Andrei approve of) - 
> https://issues.dlang.org/show_bug.cgi?id=13567 - which would be 
> doable only if private functions don't have externally visible 
> symbols.

Can you explain why _object-level visibility_ would matter in this case?

-- Johannes

Re: C style 'static' functions

[Kagamin via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer 
wrote:
I'm not so sure of that. Private functions still generate 
symbols. I think in C, there is no symbol (at least in the 
object file) for static functions or variables.


They generate hidden symbols. That's just how it implements 
private functions in C: you can't do anything else without 
mangling. You probably can't compile two C units into one object 
file if they have static functions with the same name - this 
would require mangling to make two symbols different.

Re: C style 'static' functions

[via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer 
wrote:

On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:

On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:

On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:

Try a newer compiler, this was fixed recently.


Hmm it turns out this machine has 2.0.65 on which is fairly 
ancient. I'd not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks 
for the help.


Just for the record, private is the analog of C's static. All 
private free and member functions are callable only from the 
module they are defined in. This is in contrast with C++, 
Java, C# where private members are visible only the class they 
are defined in.


I'm not so sure of that. Private functions still generate 
symbols. I think in C, there is no symbol (at least in the 
object file) for static functions or variables.


You could still call a private function in a D module via the 
mangled name I believe.


-Steve

Note: not 100% sure of all this, but this is always the way 
I've looked at it.


You're probably right about the current implementation, but I was 
talking about the intended semantics. I believe that with DIP45, 
only functions and global variables annotated with the export 
storage class would necessary have externally visible symbols.


Also, consider this enhancement request (which I think Walter and 
Andrei approve of) - 
https://issues.dlang.org/show_bug.cgi?id=13567 - which would be 
doable only if private functions don't have externally visible 
symbols.


See also: https://issues.dlang.org/show_bug.cgi?id=9893.

Re: C style 'static' functions

[Johannes Pfau via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer 
wrote:

On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:

On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:

On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:

Try a newer compiler, this was fixed recently.


Hmm it turns out this machine has 2.0.65 on which is fairly 
ancient. I'd not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks 
for the help.


Just for the record, private is the analog of C's static. All 
private free and member functions are callable only from the 
module they are defined in. This is in contrast with C++, 
Java, C# where private members are visible only the class they 
are defined in.


I'm not so sure of that. Private functions still generate 
symbols. I think in C, there is no symbol (at least in the 
object file) for static functions or variables.


You could still call a private function in a D module via the 
mangled name I believe.


-Steve

Note: not 100% sure of all this, but this is always the way 
I've looked at it.


That's correct. We unfortunately can't do certain optimizations 
because of this (executable size related: removing unused or 
inlined only functions, ...).


The reason we can't make private functions object local are 
templates. A public template can access private functions, but 
the template instance may be emitted to another object. And as 
templates can't be checzked speculatively we don't even know if 
there's a template accessing a private function.


Dlls on Windows face a similar problem. Once we get the export 
templates proposed in earlier Dll discussions we can make 
non-exported, private functions object local.

Re: C style 'static' functions

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:

On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:

On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:

Try a newer compiler, this was fixed recently.


Hmm it turns out this machine has 2.0.65 on which is fairly ancient. 
I'd not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks for the help.


Just for the record, private is the analog of C's static. All private 
free and member functions are callable only from the module they are 
defined in. This is in contrast with C++, Java, C# where private members 
are visible only the class they are defined in.


I'm not so sure of that. Private functions still generate symbols. I 
think in C, there is no symbol (at least in the object file) for static 
functions or variables.


You could still call a private function in a D module via the mangled 
name I believe.


-Steve

Note: not 100% sure of all this, but this is always the way I've looked 
at it.

Re: C style 'static' functions

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-07-19 14:11, John Burton wrote:

Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd 
not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks for the help.


I suspected something like this :). Nice to hear that you sorted it out.

--
/Jacob Carlborg

Re: C style 'static' functions

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 12:16:46 UTC, John Burton wrote:



Looks like it's https://wiki.dlang.org/DIP22 that changed this


Specifically, it was fixed in DMD 2.071.0 released in April of 
last year:


http://dlang.org/changelog/2.071.0.html#dip22

Re: C style 'static' functions

[via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:

On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:

Try a newer compiler, this was fixed recently.


Hmm it turns out this machine has 2.0.65 on which is fairly 
ancient. I'd not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks for 
the help.


Just for the record, private is the analog of C's static. All 
private free and member functions are callable only from the 
module they are defined in. This is in contrast with C++, Java, 
C# where private members are visible only the class they are 
defined in.

Re: C style 'static' functions

[John Burton via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 12:15:05 UTC, Mike Parker wrote:

On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:

On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:

Try a newer compiler, this was fixed recently.


Hmm it turns out this machine has 2.0.65 on which is fairly 
ancient. I'd not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks for 
the help.


Ah, great!


Looks like it's https://wiki.dlang.org/DIP22 that changed this

Re: C style 'static' functions

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:

On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:

Try a newer compiler, this was fixed recently.


Hmm it turns out this machine has 2.0.65 on which is fairly 
ancient. I'd not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks for 
the help.


Ah, great!

Re: C style 'static' functions

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 11:52:09 UTC, John Burton wrote:


 lib1.d 

private void init()
{
// init function used only as an implementation detail
}

void mything()
{
init();
}


 lib2.d -

void init()
{
// init function meant to be used as part of the module 
interface

}

 main.d 

import lib1;
import lib2;

void main()
{
init();  // This is meant to call lib2.init because it's 
the only
 // function of that name. lib1.init() is supposed 
to be
 // an entirely internal implementation detail of 
lib1
 // Even though I can't call lib1.init() because 
it's private

 // this call still shows up as ambigous.
 //
 // In C I'd write "static void init()" in lib1.d 
to indicate
 // that the function was entirely local to that 
file. However static

 // does not appear to have that same effect in D
}


This should work as you expect, as that's what private in module 
scope is supposed to do. And it does work for me 2.074.1. There 
was a bug with the visibility of module-private symbols in the D 
frontend that was fixed a couple of releases back (can't recall 
off hand which version). So if you're using an older version of 
DMD, or a version of LDC or GDC that uses an older version of the 
frontend, then you'll still encounter the bug.


The workaround (until you get a compiler with a more recent 
frontend) is to use the fully qualified name (FQN) of the 
function you want to call, in this case: lib2.init();

Re: C style 'static' functions

[John Burton via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:

Try a newer compiler, this was fixed recently.


Hmm it turns out this machine has 2.0.65 on which is fairly 
ancient. I'd not realized this machine had not been updated.


Sorry for wasting everyones' time if that's so, and thanks for 
the help.

Re: C style 'static' functions

[Kagamin via Digitalmars-d-learn]

Try a newer compiler, this was fixed recently.

Re: C style 'static' functions

[John Burton via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 11:31:32 UTC, Jacob Carlborg wrote:

On 2017-07-19 09:22, John Burton wrote:
In C I can declare a function 'static' and it's only visible 
from within that implementation file. So I can have a static 
function 'test' in code1.c and another non static function 
'test' in utils.c and assuming a suitable prototype I can use 
'test' in my program and the one in code1.c will not interfere.


In D it seems that declaring functions as static in a module 
does not affect visibility outside of a module. So if I 
declare a static function in one module with a specific name 
that is just used in internally for the implementation, and 
then define a function with the same name in another module 
that is intended to by 'exported' then in my main program they 
still conflict and I have to take steps to avoid this.


It looked as if I could use 'private' instead of static but 
although this prevents me from calling the "private" function, 
it still conflicts with the one I want to call.


In C++ I could use static or an anonymous namespace for 
implementation functions, but there doesn't seem to be 
anything similar in D.
Is there any way to achieve what I want in D (Private 
implementation functions)


I think it would be easier if you provide a small code example 
of what you want to achieve.



Here is an artificial example of what I mean. The point is that I 
can break main.d from compiling by adding what is meant to be a 
purely internal implementation detail inside  of lib1. - In C I 
can make internal functions static to avoid this... Im D, none of 
static, package, private etc seem to do this. They prevent it 
from being called but don't hide the existence of the function 
from the module importing it.


If there is no way to achieve this it's not a big problem, I'm 
just curious now :)



 lib1.d 

private void init()
{
// init function used only as an implementation detail
}

void mything()
{
init();
}


 lib2.d -

void init()
{
// init function meant to be used as part of the module 
interface

}

 main.d 

import lib1;
import lib2;

void main()
{
init();  // This is meant to call lib2.init because it's the 
only
 // function of that name. lib1.init() is supposed to 
be

 // an entirely internal implementation detail of lib1
 // Even though I can't call lib1.init() because it's 
private

 // this call still shows up as ambigous.
 //
 // In C I'd write "static void init()" in lib1.d to 
indicate
 // that the function was entirely local to that 
file. However static

 // does not appear to have that same effect in D
}

Re: C style 'static' functions

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-07-19 09:22, John Burton wrote:
In C I can declare a function 'static' and it's only visible from within 
that implementation file. So I can have a static function 'test' in 
code1.c and another non static function 'test' in utils.c and assuming a 
suitable prototype I can use 'test' in my program and the one in code1.c 
will not interfere.


In D it seems that declaring functions as static in a module does not 
affect visibility outside of a module. So if I declare a static function 
in one module with a specific name that is just used in internally for 
the implementation, and then define a function with the same name in 
another module that is intended to by 'exported' then in my main program 
they still conflict and I have to take steps to avoid this.


It looked as if I could use 'private' instead of static but although 
this prevents me from calling the "private" function, it still conflicts 
with the one I want to call.


In C++ I could use static or an anonymous namespace for implementation 
functions, but there doesn't seem to be anything similar in D.
Is there any way to achieve what I want in D (Private implementation 
functions)


I think it would be easier if you provide a small code example of what 
you want to achieve.


--
/Jacob Carlborg

Re: C style 'static' functions

[EnterYourNameHere via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 07:22:48 UTC, John Burton wrote:
In C I can declare a function 'static' and it's only visible 
from within that implementation file. So I can have a static 
function 'test' in code1.c and another non static function 
'test' in utils.c and assuming a suitable prototype I can use 
'test' in my program and the one in code1.c will not interfere.


In D it seems that declaring functions as static in a module 
does not affect visibility outside of a module.


Indeed, static is not a visibility attribute and for a free 
function static is mostly a no-op. So far i've only seen a 
meaningful static free func once and it was used as template 
value parameter.


So if I declare a static function in one module with a specific 
name that is just used in internally for the implementation, 
and then define a function with the same name in another module 
that is intended to by 'exported' then in my main program they 
still conflict and I have to take steps to avoid this.


It looked as if I could use 'private' instead of static but 
although this prevents me from calling the "private" function, 
it still conflicts with the one I want to call.


In C++ I could use static or an anonymous namespace for 
implementation functions, but there doesn't seem to be anything 
similar in D.
Is there any way to achieve what I want in D (Private 
implementation functions)


If what you want is an overload that has the same signature, 
which is not really possible, then you'd rather use a function 
template:


enum Internal
{
   no,
   yes
}

void foo(Internal Itr = Internal.no)()
{
static if (Itr) {}
else {}
}

That should do the trick, although i don't know the context.

Re: C style 'static' functions

[John Burton via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 07:51:11 UTC, Gary Willoughby wrote:

On Wednesday, 19 July 2017 at 07:22:48 UTC, John Burton wrote:
In C++ I could use static or an anonymous namespace for 
implementation functions, but there doesn't seem to be 
anything similar in D.
Is there any way to achieve what I want in D (Private 
implementation functions)


Try the package keyword: 
https://dlang.org/spec/attribute.html#visibility_attributes


This appears to still have the same issue. I can't use the 
"package" function in the main program but it still conflicts 
with the one I can use from a different module. Unless I'm doing 
it wrong...

Re: C style 'static' functions

[Gary Willoughby via Digitalmars-d-learn]

On Wednesday, 19 July 2017 at 07:22:48 UTC, John Burton wrote:
In C++ I could use static or an anonymous namespace for 
implementation functions, but there doesn't seem to be anything 
similar in D.
Is there any way to achieve what I want in D (Private 
implementation functions)


Try the package keyword: 
https://dlang.org/spec/attribute.html#visibility_attributes

C style 'static' functions

[John Burton via Digitalmars-d-learn]

In C I can declare a function 'static' and it's only visible from 
within that implementation file. So I can have a static function 
'test' in code1.c and another non static function 'test' in 
utils.c and assuming a suitable prototype I can use 'test' in my 
program and the one in code1.c will not interfere.


In D it seems that declaring functions as static in a module does 
not affect visibility outside of a module. So if I declare a 
static function in one module with a specific name that is just 
used in internally for the implementation, and then define a 
function with the same name in another module that is intended to 
by 'exported' then in my main program they still conflict and I 
have to take steps to avoid this.


It looked as if I could use 'private' instead of static but 
although this prevents me from calling the "private" function, it 
still conflicts with the one I want to call.


In C++ I could use static or an anonymous namespace for 
implementation functions, but there doesn't seem to be anything 
similar in D.
Is there any way to achieve what I want in D (Private 
implementation functions)

static functions associated with enums

[Dan]

I have an enum, say:

enum AssetCategory {
  Investment,
  PrimaryResidence,
  FamilyProperty,
  FinancialInstrument
}

and I have functions that convert to/from strings to be used in 
Json (via vibe json). The vibe wants to call out to user supplied 
toJson/fromJson if both functions are provided and the test for 
it is:


Json serializeToJson(T)(T value) {
...
 static if( __traits(compiles, value = 
T.fromJson(value.toJson())) ){

   return value.toJson();
...
}

I would like to use this feature to have the json output the 
string instead of numeric value (while still retaining numeric 
value in data structures). The toJson/fromJson functions below 
are close. They allow for this:


if( __traits(compiles, t.fromJson(t.toJson()) ))

to be true - but that is not the same thing. Is there a trickery 
to associate a static function with an enum? (e.g. 
AssetCategory.fromJson(json)) )


Thanks
Dan
---

static void fromJson(ref AssetCategory assetType, Json src) {
  string value = cast(string)src;
  writeln(value is ,value);
  final switch(value) {
  case Investment: { assetType = AssetCategory.Investment; 
break; }
  case PrimaryResidence: { assetType = 
AssetCategory.PrimaryResidence; break; }
  case FamilyProperty: { assetType = 
AssetCategory.FamilyProperty; break; }
  case FinancialInstrument: { assetType = 
AssetCategory.FinancialInstrument; break; }

  }
}

static Json toJson(AssetCategory assetType) {
  auto result = Json();
  result = text(assetType);
  return result;
}

Re: static functions associated with enums

[Ali Çehreli]

On 03/21/2013 01:34 PM, Dan wrote:

 Json serializeToJson(T)(T value) {
 ...
 static if( __traits(compiles, value = T.fromJson(value.toJson())) ){

It looks like fromJson must be a static member function because the 
condition is written in a way that fromJson is called on the type 
itself. (I don't know any trick to bind that to a regular function.)


It may not be suitable in your case but wrapping the enum inside a 
struct is a solution (struct AssetCategory below):


import std.stdio;
import std.conv;

struct Json
{
string s;

this(string s) {
writefln(constructing with %s, s);
this.s = s;
}

T opCast(T : string)() const
{
return s;
}
}

Json serializeToJson(T)(T value) {
static if( __traits(compiles, value = T.fromJson(value.toJson())) )
{
return value.toJson();

} else {
return Json(NOT GOOD: DEFAULT BEHAVIOR);
}
}

enum AssetCategoryType {
  Investment,
  PrimaryResidence,
  FamilyProperty,
  FinancialInstrument
}

struct AssetCategory
{
AssetCategoryType assetType;

alias assetType this;

static AssetCategory fromJson(Json src) {
string value = cast(string)src;
return AssetCategory(value.to!AssetCategoryType);
}
}

static Json toJson(AssetCategory assetType) {
  auto result = Json();
  result = Json(text(assetType));
  return result;
}

void main()
{
auto category = AssetCategory(AssetCategoryType.FamilyProperty);
auto json = serializeToJson(category);
writeln(json);

// Test fromJson
assert(AssetCategory.fromJson(Json(PrimaryResidence)) ==
   AssetCategory(AssetCategoryType.PrimaryResidence));
}

Ali

static functions?

[p0xel]

I pretty sure I'm an idiot.

[code]
class foo {
public static int bar() {
return 0;
}
}
[/code]

How do I call bar() without creating an instance of foo? 
foo.bar() results in Error: undefined identifier 'bar'


I'm having a really hard time finding anything related to D in 
general.

Re: static functions?

[p0xel]

This seems to work when the class is in the same file as main(), 
but if I move it to it's own file and use import foo it errors. 
What am I missing?

Re: static functions?

[jerro]

On Sunday, 20 May 2012 at 21:19:14 UTC, p0xel wrote:
This seems to work when the class is in the same file as 
main(), but if I move it to it's own file and use import foo 
it errors. What am I missing?


When you write import foo; and then foo.bar, the compiler 
thinks that
you a referring to a global function bar in module foo. To call 
static function bar of class foo in module foo write 
foo.foo.bar(). Or you could write import foo : foo; to import 
just the class foo from module foo and not the entire module.

Re: static functions?

[Mike Parker]

On 5/21/2012 6:32 AM, jerro wrote:

On Sunday, 20 May 2012 at 21:19:14 UTC, p0xel wrote:

This seems to work when the class is in the same file as main(), but
if I move it to it's own file and use import foo it errors. What am
I missing?


When you write import foo; and then foo.bar, the compiler thinks that
you a referring to a global function bar in module foo. To call static
function bar of class foo in module foo write foo.foo.bar(). Or you
could write import foo : foo; to import just the class foo from module
foo and not the entire module.


Or even better, name your module foo.d, and name your class Foo. Then...

import foo;

void main()
{
Foo.bar();
}

That's also the general convention.

Re: Static functions in immutable types...

[Michal Minich]

Hello Tomek,


Dnia 07-12-2009 o 11:34:52 Michal Minich michal.min...@gmail.com
napisał(a):


Hello Tomek,


... don't make sense. So is there a reason why they aren't excluded
from  the everything in an immutable is immutable rule?
Tomek

Immutable static member function could be useful...

marking struct or class as const or immutable is the same as marking
every its member so. The problem I see is in definition of what const
or  immutable member function means:

from D specs: Immutable member functions are guaranteed that the
object  and anything referred to by the this reference is immutable.

Which applies both to instance and s static functions. I think the
above  definition should apply only to instance functions. Static
const or  immutable functions should  be defined as:

Immutable static member functions are guaranteed that the static
variables of object and anything referred to by these variables is
immutable.

static member function cannot modify member variables already,
because  they do not have this pointer. They would be only allowed to
modify its  arguments and global variables; they would be something
like pure  functions for the congaing type, but not for other world.

I'm not sure how this semantics could be useful in practice, but it
seems definitely better to me than erroring out on static function
inside immutable type.


If by the lot of text above you meant it's a compiler bug, I agree :-)
http://d.puremagic.com/issues/show_bug.cgi?id=3598

Tomek



I'm glad we agreed it is a bug :-)

How about the semantics I proposed ? If you agree I would include it in the 
bug text.

Re: Static functions in immutable types...

[Steven Schveighoffer]

On Mon, 07 Dec 2009 05:34:52 -0500, Michal Minich  
michal.min...@gmail.com wrote:



Hello Tomek,


... don't make sense. So is there a reason why they aren't excluded
from  the everything in an immutable is immutable rule?
 Tomek



Immutable static member function could be useful...

marking struct or class as const or immutable is the same as marking  
every its member so. The problem I see is in definition of what const or  
immutable member function means:


from D specs: Immutable member functions are guaranteed that the object  
and anything referred to by the this reference is immutable.


Which applies both to instance and s static functions. I think the above  
definition should apply only to instance functions. Static const or  
immutable functions should  be defined as:


Immutable static member functions are guaranteed that the static  
variables of object and anything referred to by these variables is  
immutable.




Let's say there was an immutable static member function which treated the  
static data members as immutable.  This means nobody else can change  
them.  This means that there cannot be any static member functions that  
are not immutable.  This means that the data members cannot be marked as  
public unless they are also marked as immutable.


In this case, the equivalent thing is to mark all static data members as  
immutable, and leave the static function as a normal function.


This is why the OP said they don't make sense  Although his statement  
really should be immutable static functions don't make sense, not  
static functions in immutable types don't make sense, as they do make  
sense, they should just not be marked as immutable.


The bug filed is absolutely a bug, it should be possible to have a normal  
static function inside an immutable type.


-Steve

Re: Static functions in immutable types...

[Michal Minich]

Hello Steven,

I'm sorry, but have big trouble to understand what you want to say. So I 
will comment to what I can, and try to rephrase my post.



On Mon, 07 Dec 2009 05:34:52 -0500, Michal Minich
michal.min...@gmail.com wrote:


Hello Tomek,


... don't make sense. So is there a reason why they aren't excluded
from  the everything in an immutable is immutable rule?
Tomek

Immutable static member function could be useful...

marking struct or class as const or immutable is the same as marking
every its member so. The problem I see is in definition of what const
or  immutable member function means:

from D specs: Immutable member functions are guaranteed that the
object  and anything referred to by the this reference is immutable.

Which applies both to instance and s static functions. I think the
above  definition should apply only to instance functions. Static
const or  immutable functions should  be defined as:

Immutable static member functions are guaranteed that the static
variables of object and anything referred to by these variables is
immutable.


Let's say there was an immutable static member function which treated
the  static data members as immutable.  This means nobody else can
change  them.  


Couldn't they be changed from outside of the type?


This means that there cannot be any static member
functions that  are not immutable.  This means that the data members
cannot be marked as  public unless they are also marked as immutable.

In this case, the equivalent thing is to mark all static data members
as  immutable, and leave the static function as a normal function.

This is why the OP said they don't make sense  Although his
statement  really should be immutable static functions don't make
sense, not  static functions in immutable types don't make sense,
as they do make  sense, they should just not be marked as immutable.

The bug filed is absolutely a bug, it should be possible to have a
normal  static function inside an immutable type.


Currently everything is marked as immutable in immutable type. Do you think 
it is good to have exception for static function?


-Steve



So to rephrase:
1. from D specs:  A struct declaration can have a storage class of const, 
immutable or shared. It has an equivalent effect as declaring each member 
of the struct as const, immutable or shared. -- I'm ok with this, it is 
simple.


2. from D specs: Immutable member functions are guaranteed that the object 
and anything referred to by the this reference is immutable. -- this rule 
is wrong, because it mentions *this* and at the same time it applies to static 
member functions, which obviously doesn't have *this* reference.


3. I propose changing rule in point 2 to: Immutable *non-static* member 
functions are guaranteed that the object and anything referred to by the 
this reference is immutable. and adding this one: Immutable static member 
functions are guaranteed that the static variables of object and anything 
referred to by these variables is immutable


And I'm asking if the change is reasonable - Or how should be defined semantics 
of static immutable member function?

Re: Static functions in immutable types...

[Steven Schveighoffer]

On Tue, 08 Dec 2009 11:53:03 -0500, Michal Minich  
michal.min...@gmail.com wrote:



Hello Steven,

I'm sorry, but have big trouble to understand what you want to say. So I  
will comment to what I can, and try to rephrase my post.



On Mon, 07 Dec 2009 05:34:52 -0500, Michal Minich
michal.min...@gmail.com wrote:


Hello Tomek,


... don't make sense. So is there a reason why they aren't excluded
from  the everything in an immutable is immutable rule?
Tomek

Immutable static member function could be useful...
 marking struct or class as const or immutable is the same as marking
every its member so. The problem I see is in definition of what const
or  immutable member function means:
 from D specs: Immutable member functions are guaranteed that the
object  and anything referred to by the this reference is immutable.
 Which applies both to instance and s static functions. I think the
above  definition should apply only to instance functions. Static
const or  immutable functions should  be defined as:
 Immutable static member functions are guaranteed that the static
variables of object and anything referred to by these variables is
immutable.


Let's say there was an immutable static member function which treated
the  static data members as immutable.  This means nobody else can
change  them.


Couldn't they be changed from outside of the type?


That would be a violation of immutability.  If they can change, then they  
are not immutable.  Note they cannot be temporarily immutable, they are  
immutable from the moment that something casts it to immutable.  It is up  
to you, the programmer, to ensure that no mutable references exist after  
you perform the cast.  Using a mutable reference to immutable data results  
in undefined behavior.


To illustrate:

int x;
immutable(int) *y;

void foo()
{
   y = cast(immutable(int)*)y;  // no longer allowed to use x!
}

void bar()
{
   foo();
   x++; // undefined behavior!
}




This means that there cannot be any static member
functions that  are not immutable.  This means that the data members
cannot be marked as  public unless they are also marked as immutable.
 In this case, the equivalent thing is to mark all static data members
as  immutable, and leave the static function as a normal function.
 This is why the OP said they don't make sense  Although his
statement  really should be immutable static functions don't make
sense, not  static functions in immutable types don't make sense,
as they do make  sense, they should just not be marked as immutable.
 The bug filed is absolutely a bug, it should be possible to have a
normal  static function inside an immutable type.


Currently everything is marked as immutable in immutable type. Do you  
think it is good to have exception for static function?


Either you make an exception for a static function -or- applying immutable  
to a static function is a no-op.  There is no reason to restrict immutable  
types from having static functions.



So to rephrase:
1. from D specs:  A struct declaration can have a storage class of  
const, immutable or shared. It has an equivalent effect as declaring  
each member of the struct as const, immutable or shared. -- I'm ok with  
this, it is simple.


2. from D specs: Immutable member functions are guaranteed that the  
object and anything referred to by the this reference is immutable. --  
this rule is wrong, because it mentions *this* and at the same time it  
applies to static member functions, which obviously doesn't have *this*  
reference.


3. I propose changing rule in point 2 to: Immutable *non-static* member  
functions are guaranteed that the object and anything referred to by the  
this reference is immutable. and adding this one: Immutable static  
member functions are guaranteed that the static variables of object and  
anything referred to by these variables is immutable


And I'm asking if the change is reasonable - Or how should be defined  
semantics of static immutable member function?


static immutable member functions are either illegal in the case where all  
static member data is not immutable or equivalent to static member  
functions in the case where all the member data is immutable.


I agree the rule needs to change, here is how I would change it:

A struct declaration can have a storage class of const, immutable or  
shared. It has an equivalent effect as declaring each member of the struct  
except static functions as const, immutable or shared.


Immutable/const/shared non-static member functions are guaranteed that the  
object and anything referred to by the this reference is  
immutable/const/shared.  Declaring a static member function is  
immutable/const/shared is considered an error.


-Steve

Re: Static functions in immutable types...

[Michal Minich]

On Tue, 08 Dec 2009 12:23:53 -0500, Steven Schveighoffer wrote:


 That would be a violation of immutability.  If they can change, then
 they are not immutable.  Note they cannot be temporarily immutable,
 they are immutable from the moment that something casts it to immutable.
  It is up to you, the programmer, to ensure that no mutable references
 exist after you perform the cast.  Using a mutable reference to
 immutable data results in undefined behavior.
 
 To illustrate:
 
 int x;
 immutable(int) *y;
 
 void foo()
 {
 y = cast(immutable(int)*)y;  // no longer allowed to use x!
 }
 
 void bar()
 {
 foo();
 x++; // undefined behavior!
 }
 
This is misunderstanding, I'm talking about interaction of mutable static 
data members with immutable static member function, as in this example:

struct S
{
static int x;

static void foo () immutable
{
   // x = 3; // should be error, because immutable static member 
function cannot change mutable static data members.
}
}

 
 This means that there cannot be any static member functions that  are
 not immutable.  This means that the data members cannot be marked as 
 public unless they are also marked as immutable.
  In this case, the equivalent thing is to mark all static data members
 as  immutable, and leave the static function as a normal function.
  This is why the OP said they don't make sense  Although his
 statement  really should be immutable static functions don't make
 sense, not  static functions in immutable types don't make sense,
 as they do make  sense, they should just not be marked as immutable.
  The bug filed is absolutely a bug, it should be possible to have a
 normal  static function inside an immutable type.

 Currently everything is marked as immutable in immutable type. Do you
 think it is good to have exception for static function?
 
 Either you make an exception for a static function -or- applying
 immutable to a static function is a no-op.  There is no reason to
 restrict immutable types from having static functions.
 
 So to rephrase:
 1. from D specs:  A struct declaration can have a storage class of
 const, immutable or shared. It has an equivalent effect as declaring
 each member of the struct as const, immutable or shared. -- I'm ok
 with this, it is simple.

 2. from D specs: Immutable member functions are guaranteed that the
 object and anything referred to by the this reference is immutable. --
 this rule is wrong, because it mentions *this* and at the same time it
 applies to static member functions, which obviously doesn't have *this*
 reference.

 3. I propose changing rule in point 2 to: Immutable *non-static*
 member functions are guaranteed that the object and anything referred
 to by the this reference is immutable. and adding this one: Immutable
 static member functions are guaranteed that the static variables of
 object and anything referred to by these variables is immutable

 And I'm asking if the change is reasonable - Or how should be defined
 semantics of static immutable member function?
 
 static immutable member functions are either illegal in the case where
 all static member data is not immutable or equivalent to static member
 functions in the case where all the member data is immutable.
 
 I agree the rule needs to change, here is how I would change it:
 
 A struct declaration can have a storage class of const, immutable or
 shared. It has an equivalent effect as declaring each member of the
 struct except static functions as const, immutable or shared.
 
 Immutable/const/shared non-static member functions are guaranteed that
 the object and anything referred to by the this reference is
 immutable/const/shared.  Declaring a static member function is
 immutable/const/shared is considered an error.

The change I proposed is in at least line with existing functionality. 
What is a benefit of not having immutable member functions as you 
proposed?

 
 -Steve

Moved the discussion to digitalmars.D group. please reply there

Re: Static functions in immutable types...

[Michal Minich]

Hello Tomek,


... don't make sense. So is there a reason why they aren't excluded
from  the everything in an immutable is immutable rule?

Tomek



Immutable static member function could be useful...

marking struct or class as const or immutable is the same as marking every 
its member so. The problem I see is in definition of what const or immutable 
member function means:


from D specs: Immutable member functions are guaranteed that the object 
and anything referred to by the this reference is immutable.


Which applies both to instance and s static functions. I think the above 
definition should apply only to instance functions. Static const or immutable 
functions should  be defined as:


Immutable static member functions are guaranteed that the static variables 
of object and anything referred to by these variables is immutable.


static member function cannot modify member variables already, because they 
do not have this pointer. They would be only allowed to modify its arguments 
and global variables; they would be something like pure functions for the 
congaing type, but not for other world.


I'm not sure how this semantics could be useful in practice, but it seems 
definitely better to me than erroring out on static function inside immutable 
type.

Re: Static functions in immutable types...

[Tomek Sowiński]

Dnia 07-12-2009 o 11:34:52 Michal Minich michal.min...@gmail.com  
napisał(a):



Hello Tomek,


... don't make sense. So is there a reason why they aren't excluded
from  the everything in an immutable is immutable rule?
 Tomek



Immutable static member function could be useful...

marking struct or class as const or immutable is the same as marking  
every its member so. The problem I see is in definition of what const or  
immutable member function means:


from D specs: Immutable member functions are guaranteed that the object  
and anything referred to by the this reference is immutable.


Which applies both to instance and s static functions. I think the above  
definition should apply only to instance functions. Static const or  
immutable functions should  be defined as:


Immutable static member functions are guaranteed that the static  
variables of object and anything referred to by these variables is  
immutable.


static member function cannot modify member variables already, because  
they do not have this pointer. They would be only allowed to modify its  
arguments and global variables; they would be something like pure  
functions for the congaing type, but not for other world.


I'm not sure how this semantics could be useful in practice, but it  
seems definitely better to me than erroring out on static function  
inside immutable type.




If by the lot of text above you meant it's a compiler bug, I agree :-)
http://d.puremagic.com/issues/show_bug.cgi?id=3598


Tomek

Static functions in immutable types...

[Tomek Sowiński]

... don't make sense. So is there a reason why they aren't excluded from  
the everything in an immutable is immutable rule?



Tomek