Re: Inferred attributes errors in template function.
On Friday, 27 May 2022 at 09:41:32 UTC, user1234 wrote: [...] on a side note that's funny how dmd manages to systematically print the less interesting message in both case. They are actually correct, I dont know why at some point I thought there was a problem. For the float one it's oviously not pure and for the int one it's not safe... OP wants better error message.
Re: Inferred attributes errors in template function.
On Friday, 27 May 2022 at 08:39:08 UTC, vit wrote:
Is in dmd some flag that print errors similarly to this?:
```d
void main()@safe pure{
foo!long();
foo!float();
//Error: `pure` function `D main` cannot call impure
function `onlineapp.foo!float.foo`
//Error: potentially `pure` function
`onlineapp.foo!float.foo` cannot call impure function
`onlineapp.bar!float.bar`
//Error: potentially `pure` function
`onlineapp.bar!float.bar` cannot access mutable static data `i`
```
No, there is nothing like this, at least not yet. It's being
worked on, though.
https://github.com/dlang/dmd/pull/13957
https://github.com/dlang/dmd/pull/12383
Re: Inferred attributes errors in template function.
On Friday, 27 May 2022 at 08:39:08 UTC, vit wrote:
Hello, I have this problem:
```d
static int i;
void bar(T)(){
static if(is(T == int))
(()@system => 1)();
static if(is(T == float))
i = 42;
}
void foo(T)(){
bar!T();
}
void main()@safe pure{
foo!long();
foo!float(); //Error: `pure` function `D main` cannot call
impure function `onlineapp.foo!float.foo`
foo!int(); //Error: `@safe` function `D main` cannot call
`@system` function `onlineapp.foo!int.foo`
}
```
When template function foo is called and its inferred
attributes are not compatible with attributes of main, errors
are not really useful. Compiler print that foo!float is not
pure or foo!int is not @safe but doesn't tell why. Is in dmd
some flag that print errors similarly to this?:
```d
void main()@safe pure{
foo!long();
foo!float();
//Error: `pure` function `D main` cannot call impure
function `onlineapp.foo!float.foo`
//Error: potentially `pure` function
`onlineapp.foo!float.foo` cannot call impure function
`onlineapp.bar!float.bar`
//Error: potentially `pure` function
`onlineapp.bar!float.bar` cannot access mutable static data `i`
foo!int();
//Error: `@safe` function `D main` cannot call `@system`
function `onlineapp.foo!int.foo`
//Error: potentially `@safe` function
`onlineapp.foo!int.foo` cannot call `@system` function
`onlineapp.bar!int.bar`
//Error: potentially `@safe` function
`onlineapp.bar!int.bar` cannot call `@system` delegate
`onlineapp.bar!int.bar.__lambda1`
}
```
Use `-verrors=context` for dmd
```d
static int i;
void bar(T)(){
static if(is(T == int))
(()@system => 1)();
static if(is(T == float))
i = 42;
}
void foo(T)(){
bar!T();
}
void main()@safe pure{
foo!long();
foo!float(); /+ onlineapp.d(16): Error: `pure` function `D main`
cannot call impure function `onlineapp.foo!float.foo`
foo!float();
^ +/
foo!int(); /+onlineapp.d(18): Error: `@safe` function `D main`
cannot call `@system` function `onlineapp.foo!int.foo`
foo!int();
^ +/
}
```
Re: Inferred attributes errors in template function.
On Friday, 27 May 2022 at 08:39:08 UTC, vit wrote:
Hello, I have this problem:
```d
static int i;
void bar(T)(){
static if(is(T == int))
(()@system => 1)();
static if(is(T == float))
i = 42;
}
void foo(T)(){
bar!T();
}
void main()@safe pure{
foo!long();
foo!float(); //Error: `pure` function `D main` cannot call
impure function `onlineapp.foo!float.foo`
foo!int(); //Error: `@safe` function `D main` cannot call
`@system` function `onlineapp.foo!int.foo`
}
```
[...]
on a side note that's funny how dmd manages to systematically
print the less interesting message in both case.
Re: Conditional Attributes
On Thursday, 20 February 2020 at 17:41:54 UTC, Dennis wrote:
On Tuesday, 18 February 2020 at 17:11:55 UTC, Marcel wrote:
Say I have a struct where every member function can either be
static or not depending on a template parameter. Is there a
simple way to do this?
The best I can think of is:
```
mixin template maybeStatic() {
void foo() {
// implementation
}
}
struct S(bool condition) {
static if (condition) {
static {
mixin maybeStatic;
}
} else {
mixin maybeStatic;
}
}
```
What do you need this for? It seems like an unusual situation
to me.
That will do, thank you!
I'm making an allocator library similar to what Andrei
Alexandrescu presented at CppCon. Since some allocators may not
have state, those that inherit* from them may need to have every
member function marked as static.
*I'm using mixins instead of inheritance.
Re: Conditional Attributes
On Friday, 21 February 2020 at 01:41:21 UTC, Steven Schveighoffer
wrote:
On 2/18/20 12:11 PM, Marcel wrote:
Hello!
Say I have a struct where every member function can either be
static or not depending on a template parameter. Is there a
simple way to do this? Like, for example:
struct Foo(Condition)
{
static if (Condition) static:
void Bar() {}
void Baz() {}
}
Since D conditional compilation must always be a valid
declaration or statement, you cannot do something like this.
The closest you can do is to use mixins, which means you have
to write everything inside strings.
It has been proposed quite a few times to have a way to
enable/disable attributes based on a compile-time boolean. But
it's never come close to getting included.
-Steve
That's a shame...
Re: Conditional Attributes
On 2/18/20 12:11 PM, Marcel wrote:
Hello!
Say I have a struct where every member function can either be static or
not depending on a template parameter. Is there a simple way to do this?
Like, for example:
struct Foo(Condition)
{
static if (Condition) static:
void Bar() {}
void Baz() {}
}
Since D conditional compilation must always be a valid declaration or
statement, you cannot do something like this.
The closest you can do is to use mixins, which means you have to write
everything inside strings.
It has been proposed quite a few times to have a way to enable/disable
attributes based on a compile-time boolean. But it's never come close to
getting included.
-Steve
Re: Conditional Attributes
On Tuesday, 18 February 2020 at 17:11:55 UTC, Marcel wrote:
Say I have a struct where every member function can either be
static or not depending on a template parameter. Is there a
simple way to do this?
The best I can think of is:
```
mixin template maybeStatic() {
void foo() {
// implementation
}
}
struct S(bool condition) {
static if (condition) {
static {
mixin maybeStatic;
}
} else {
mixin maybeStatic;
}
}
```
What do you need this for? It seems like an unusual situation to
me.
Re: Get attributes of a field?
On 2019-04-02 15:23, Alex wrote:
__traits(getAttributes, T)
Requires a type and a field is unfortunately not a type ;/
enum attr;
struct Foo
{
@attr int a;
}
void main()
{
alias a = __traits(getAttributes, Foo.a);
}
--
/Jacob Carlborg
Re: Get attributes of a field?
On Tuesday, 2 April 2019 at 13:36:47 UTC, Alex wrote: On Tuesday, 2 April 2019 at 13:23:37 UTC, Alex wrote: __traits(getAttributes, T) Requires a type and a field is unfortunately not a type ;/ I'd like to be able to get the attributes without having to instantiate the base type because that is problematic and I see no reason why it has to be instantiated to get CT values. Could you provide a full example for this issue and for your other message? That makes it easier to help you Kind regards Andre
Re: Get attributes of a field?
On Tuesday, 2 April 2019 at 13:23:37 UTC, Alex wrote: __traits(getAttributes, T) Requires a type and a field is unfortunately not a type ;/ I'd like to be able to get the attributes without having to instantiate the base type because that is problematic and I see no reason why it has to be instantiated to get CT values.
Re: On Attributes
On Monday, 27 November 2017 at 20:07:08 UTC, A Guy With a Question wrote: On Monday, 27 November 2017 at 19:41:03 UTC, Adam D. Ruppe wrote: On Monday, 27 November 2017 at 19:10:04 UTC, A Guy With a One thing that is bugging me is having to mark up all of my declarations with attributes. Meh, you could also just ignore the attribute crap. Only reason I ever mess with them is if someone who is using them tries to use my code... otherwise you can pretend the spam doesn't exist and be more productive. Yeah, I'm leaning towards that direction. It seems they could have been useful if they were the default. But opting into them doesn't seem as useful, unfortunately. I'll probably continue fiddling with them, but I might just abandon using them. I also rarely put the attributes (although sincerely i think that my funcs are pure 99% of them time) but take care because recently it was announced that better code will be generated if there are scope(exit) / try-finally inside nothrow funcs: https://forum.dlang.org/thread/ovbduq$m3a$1...@digitalmars.com
Re: On Attributes
On Monday, 27 November 2017 at 19:41:03 UTC, Adam D. Ruppe wrote: On Monday, 27 November 2017 at 19:10:04 UTC, A Guy With a One thing that is bugging me is having to mark up all of my declarations with attributes. Meh, you could also just ignore the attribute crap. Only reason I ever mess with them is if someone who is using them tries to use my code... otherwise you can pretend the spam doesn't exist and be more productive. Yeah, I'm leaning towards that direction. It seems they could have been useful if they were the default. But opting into them doesn't seem as useful, unfortunately. I'll probably continue fiddling with them, but I might just abandon using them.
Re: On Attributes
On Monday, 27 November 2017 at 19:10:04 UTC, A Guy With a One thing that is bugging me is having to mark up all of my declarations with attributes. Meh, you could also just ignore the attribute crap. Only reason I ever mess with them is if someone who is using them tries to use my code... otherwise you can pretend the spam doesn't exist and be more productive.
Re: On Attributes
On Mon, Nov 27, 2017 at 07:10:04PM +, A Guy With a Question via
Digitalmars-d-learn wrote:
> Hi again!
>
> I've been trying to do my best to write idiomatically. One thing that
> is bugging me is having to mark up all of my declarations with
> attributes. Which means I'm having to remember them all. It's a bit
> much to keep in my head with every function. Is there a good way to
> reverse this (imply the attributes by default) and then turn them off
> explicitly? Like declaring them at the top of the file so they apply
> to everything below?
[...]
You can declare attributes at the top of the file by writing "attr:"
where "attr" is pure, nothrow, @nogc, etc..
However, there is currently no way to negate these attributes afterwards.
An alternative is to let the compiler do the hard work for you by
templatizing your code. Template functions and members of templated
aggregates (structs and classes) trigger attribute inference. You can
turn non-template functions into template functions by adding an empty
list of compile-time parameters:
int myfunc()(int x, int y) { ... }
This has the added advantage that if myfunc is never actually referenced
elsewhere in the code, it won't even be compiled into the executable.
Of course, this is not a perfect solution, since you can't use it if for
whatever reason your function must not be a template. One area is class
methods that must be overridden by derived classes, which can't be
template methods. There's no way around specifying explicit attributes
in that case.
T
--
The fact that anyone still uses AOL shows that even the presence of options
doesn't stop some people from picking the pessimal one. - Mike Ellis
Re: On Attributes
On 11/27/17 2:10 PM, A Guy With a Question wrote:
Hi again!
I've been trying to do my best to write idiomatically. One thing that is
bugging me is having to mark up all of my declarations with attributes.
Which means I'm having to remember them all. It's a bit much to keep in
my head with every function. Is there a good way to reverse this (imply
the attributes by default) and then turn them off explicitly? Like
declaring them at the top of the file so they apply to everything below?
You can have some degree of success with global application and inference.
Note that ALL attributes can be applied in one of 3 ways:
1. At the declaration:
@safe int foo();
@safe int bar();
2. In a scope:
@safe {
int foo();
int bar();
}
3. as a label:
@safe:
int foo();
int bar();
There are some limitations, such that it will NOT apply to functions
inside classes or structs. Also, attributes without an opposite
attribute (e.g. pure) cannot be undone once you apply at the top with a
label.
Note that templates automatically infer attributes, you do not have to
write them:
T foo(T)() {... } // implies @safe if possible
Functions which return auto also imply attributes:
auto foo() {... } // implies @safe if possible
The reason here is because the implementation of the function must be
available to properly compile, therefore the compiler can infer the
proper attributes.
Hope this helps.
-Steve
Re: Can attributes trigger functionality?
On Wednesday, 6 September 2017 at 02:43:20 UTC, Psychological Cleanup wrote: I'm having to create a lot of boiler plate code that creates "events" and corresponding properties(getter and setter). I'm curious if I can simplify this without a string mixin. If I create my own attribute like @Event double foo(); and I write any code that will trigger when the event is used and add more code(such as the setter property and events that I need? Obviously I could write some master template that scans everything, but that seems to be far too much over kill. A string mixin is probably my only option but is a bit ulgy for me. Since attributes can be defined by structures it seems natural that we could put functionality in them that are triggered when used but I'm unsure if D has such capabilities. Thanks. User defined attributes (UDAs) are in and of themselves only (compile time) introspectable decoration [1] (they only carry information). If you want to trigger specific behaviour for things that are attributed with a UDA you indeed need to some custom written active component that introspects using `__traits(getAttributes, symbol) and generates injects generates the behaviour (e.g. using a string mixin as you noted). [1] https://dlang.org/spec/attribute.html#UserDefinedAttribute
Re: Can attributes trigger functionality?
On Wednesday, 6 September 2017 at 02:43:20 UTC, Psychological
Cleanup wrote:
I'm having to create a lot of boiler plate code that creates
"events" and corresponding properties(getter and setter).
I'm curious if I can simplify this without a string mixin.
You certainly don't need a string mixin, but you do need some
code to react to the attribute.
Here's one that generates a wrapper function on-demand:
---
import std.stdio;
import std.traits;
class Test {
@cool void foo_() {
writeln("cool function called");
}
mixin CoolFunctions;
}
// our UDA
enum cool;
// adds the decorator implementation
mixin template CoolFunctions() {
template opDispatch(string name)
if(hasUDA!(__traits(getMember, typeof(this), name ~ "_"), cool)) {
auto opDispatch(Parameters!(__traits(getMember,
typeof(this), name ~ "_")) params) {
writeln("cool before");
scope(success) {
writeln("cool after");
}
return __traits(getMember, this, name ~
"_")(params);
}
}
}
void main() {
auto test = new Test();
test.foo();
}
-
No string mixin (uses a mixin template instead), and not even a
loop over the functions - it does them on-demand when used via
opDispatch.
Re: Class attributes
On Sunday, 2 October 2016 at 17:22:57 UTC, Basile B. wrote:
On Sunday, 2 October 2016 at 15:54:38 UTC, Satoshi wrote:
Hello,
why
pure @safe nothrow @nogc struct Point {
}
isn't same as
struct Point {
pure: @safe: nothrow: @nogc:
}
??
This is not specified but attributes aren't applied to the
scope created by the declaration. Which is a good thing, for
example with the visibility attributes it would be a problem,
imagine the following declarations:
struct Foo(T)
{
private struct Range // imagine that private as a inner
"private:"
{
void popFront(); // would be private !!
bool empty(); // would be private !!
T front(); // would be private !!
}
}
So this is really not something anyone would want.
But shared or abstract attribute can be applied to scope created
by class so nothrow @safe @nogc or pure should be too.
It should follow same rules as in function declaration.
void test() @safe {
void thisFunctionIsSafeToo() {
}
}
Re: Class attributes
On Sunday, 2 October 2016 at 15:54:38 UTC, Satoshi wrote:
Hello,
why
pure @safe nothrow @nogc struct Point {
}
isn't same as
struct Point {
pure: @safe: nothrow: @nogc:
}
??
This is not specified but attributes aren't applied to the scope
created by the declaration. Which is a good thing, for example
with the visibility attributes it would be a problem, imagine the
following declarations:
struct Foo(T)
{
private struct Range // imagine that private as a inner
"private:"
{
void popFront(); // would be private !!
bool empty(); // would be private !!
T front(); // would be private !!
}
}
So this is really not something anyone would want.
Re: Auto attributes for functions
On Wed, 20 Aug 2014 01:38:52 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow @nogc const
{}
Currently, just templated functions get their attributes inferred. The biggest
problem with inferring them for all functions is that you can declare a
function without defining it in the same place (e.g. if you're using .di
files), in which case the compiler has no function body to use for attribute
inferrence.
There have been discussions on ways to reasonably infer attributes under more
circumstances, but nothing has come of them yet. However, I'd expect that
there will be at least some improvements to the situation at some point given
that there is a general consensus that while the attributes are quite useful,
it's also rather annoying to have to keep typing them all.
- Jonathan M Davis
Re: Auto attributes for functions
On Wednesday, 20 August 2014 at 09:13:15 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
On Wed, 20 Aug 2014 01:38:52 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow @nogc const
{}
Currently, just templated functions get their attributes
inferred. The biggest
problem with inferring them for all functions is that you can
declare a
function without defining it in the same place (e.g. if you're
using .di
files), in which case the compiler has no function body to use
for attribute
inferrence.
There have been discussions on ways to reasonably infer
attributes under more
circumstances, but nothing has come of them yet. However, I'd
expect that
there will be at least some improvements to the situation at
some point given
that there is a general consensus that while the attributes are
quite useful,
it's also rather annoying to have to keep typing them all.
- Jonathan M Davis
Thanks guys for the info.
/uri
Re: Auto attributes for functions
On Wednesday, 20 August 2014 at 01:38:53 UTC, uri wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow @nogc const
{}
cheers,
uri
Only if they're template functions.
//inferred as @safe pure nothrow @nogc
auto fun()() {}
//Compiler treats this is @system impure throwing @gc
//(if the latter three existed)
auto fun() {}
I think Andrei suggested in the past that functions with a return
type of auto have attributes inferred for them as well, but
some people were against it, and nobody's tried implementing it
yet.
Re: Handle attributes changes
I found this, which excactly is what I want to do : http://dlang.org/phobos/std_signals.html So in other terms, I want to abstract that, maybe with an UDA ? But can I do this without compile time code changes ? Thanks again!
Re: Using attributes inside template instantiation
But if I write
@(hello) struct Hello {}
so all of the variables that have type Hello will have attribute
@(hello) like come type qualifier because attribute is a part
of declaration of Hello. Do I understand correctly?
Re: Using attributes inside template instantiation
On Thursday, 26 June 2014 at 07:11:03 UTC, Uranuz wrote:
But if I write
@(hello) struct Hello {}
so all of the variables that have type Hello will have
attribute @(hello) like come type qualifier because attribute
is a part of declaration of Hello. Do I understand correctly?
No, it is only the symbol Hello that will have the attribute
@(hello). Attributes are attached to symbols, not types or
values.
Re: Using attributes inside template instantiation
UDA's are compile-time metadata associated with a specific declaration. So in something like: @foo int x; The @foo is attached to x, but is not part of the type.
Re: Using attributes inside template instantiation
On Wed, Jun 25, 2014 at 05:10:06PM +, Chris Nicholson-Sauls via Digitalmars-d-learn wrote: UDA's are compile-time metadata associated with a specific declaration. So in something like: @foo int x; The @foo is attached to x, but is not part of the type. The term attribute is a bit confusing, especially since property is also used in the language to refer to something completely different. A better term is perhaps annotation. The @foo is an annotation on x, but its type is just int. Furthermore, the @foo annotation on it only exists at compile-type; it doesn't exist at runtime. The purpose is really to enhance compile-time introspection and metaprogramming; but what the OP wants seems to be something else altogether. Sadly, the attribute terminology has stuck, and is unlikely to change. T -- What do you get if you drop a piano down a mineshaft? A flat minor.
Re: Using attributes inside template instantiation
On Wednesday, 25 June 2014 at 17:21:21 UTC, H. S. Teoh via Digitalmars-d-learn wrote: The term attribute is a bit confusing, especially since property is also used in the language to refer to something completely different. A better term is perhaps annotation. The @foo is an annotation on x, but its type is just int. Agree whole-heartedly. I usually introduce people to the idea by referring to them as annotations, which they understand quickly, then later tell them that it's called an attribute because of reasons no one knows. I get funny looks, but at least they comprehend it. I'm not so sure it's too late to get the terminology changed, though, and I sincerely hope it will.
Re: Get attributes of type by string name
On 2013-08-02 03:02, JS wrote:
how can I get the UDA's of a type that I only know by name and only in a
CTFE.
I would like to loop over an array of names passed to a me(I don't know
their contents beforehand) and get the attributes.
I've tried to use a mixin but I can't get the mixin to work on the
string name...
e.g., mixin(alias a = __traits(getAttributes, ~type~););
You need to use a typetuple as well:
import std.typetuple;
enum attribute;
@attribute struct Foo {}
void main ()
{
alias a = TypeTuple!(__traits(getAttributes, mixin(Foo)));
pragma(msg, a);
}
--
/Jacob Carlborg
Re: Missing attributes in FunctionAttribute
On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. You can always do something like is(func == const). You may check recently pulled update to fullyQualifiedName (should be in next release) to see how it works for function types. Not obvious part probably is delegate handling. https://github.com/D-Programming-Language/phobos/pull/863
Re: Missing attributes in FunctionAttribute
On 2/10/13, Dicebot m.stras...@gmail.com wrote: On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. In the spec they're listed as member function attributes.
Re: Missing attributes in FunctionAttribute
On Sunday, 10 February 2013 at 18:25:25 UTC, Andrej Mitrovic wrote: On 2/10/13, Dicebot m.stras...@gmail.com wrote: On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. In the spec they're listed as member function attributes. Which part? Probably it refers to delegates, because it has both type qualifiers and attribute that qualifies hidden context pointer.
Re: Tidy attributes
Ary Borenszweig wrote:
bearophile wrote:
While looking for possible attribute problems to add to Bugzilla, I
have seen the following D2 program compiles and runs with no errors or
warnings:
static foo1() {}
final foo2() {}
ref foo3() {}
enum void foo5() {}
nothrow foo4() {}
pure foo6() {}
static int x1 = 10;
static x2 = 10;
void main() {}
I don't like that code, but I don't know if it's correct.
- What is a static global function in D?
- A final global function?
- Is that ref of void correct? (I think it is not)
- A enum of void function?
- What are global static variables in D?
- Are most of those attributes supposed to not need the void?
The following lines don't compile, is this supposed to be correct?
int static x3 = 10;
int enum x4 = 1;
int const x5 = 2;
Bye,
bearophile
I have discussed this subject many times, but it doesn't seem very
important to the D dev team. IIRC they said it doesn't cause any harm.
But in some real code I have seen:
static int foo() { ... }
in global scope, and I always wondered why was that static there. Maybe
the programmer thought static implied something there and now he's using
it incorrectly, and now it confused me too and probably many others. So
I think it is harmful because if the compiler allows such things than
programmers can assume that must mean something.
Please don't confuse it's not a high priority with it won't be
fixed. There are nearly 900 open compiler bugs in Bugzilla, and we can
only fix a couple of bugs per day. Compiler faults and wrong code
generation always get top priority.
Re: Tidy attributes
bearophile wrote:
While looking for possible attribute problems to add to Bugzilla, I have seen
the following D2 program compiles and runs with no errors or warnings:
static foo1() {}
final foo2() {}
ref foo3() {}
enum void foo5() {}
nothrow foo4() {}
pure foo6() {}
static int x1 = 10;
static x2 = 10;
void main() {}
I don't like that code, but I don't know if it's correct.
- What is a static global function in D?
- A final global function?
- Is that ref of void correct? (I think it is not)
- A enum of void function?
- What are global static variables in D?
- Are most of those attributes supposed to not need the void?
The following lines don't compile, is this supposed to be correct?
int static x3 = 10;
int enum x4 = 1;
int const x5 = 2;
Bye,
bearophile
I have discussed this subject many times, but it doesn't seem very
important to the D dev team. IIRC they said it doesn't cause any harm.
But in some real code I have seen:
static int foo() { ... }
in global scope, and I always wondered why was that static there. Maybe
the programmer thought static implied something there and now he's using
it incorrectly, and now it confused me too and probably many others. So
I think it is harmful because if the compiler allows such things than
programmers can assume that must mean something.
Re: Tidy attributes
On 03/11/2010 10:20 PM, bearophile wrote:
While looking for possible attribute problems to add to Bugzilla, I have seen
the following D2 program compiles and runs with no errors or warnings:
static foo1() {}
static does not apply to free functions, I would guess this means the
same as auto.
final foo2() {}
ref foo3() {}
enum void foo5() {}
Wow.
nothrow foo4() {}
pure foo6() {}
Would guess for auto here. Not tidy, as you say :)
static int x1 = 10;
static x2 = 10;
static here means 'known at compile time', I think.
- What is a static global function in D?
It means nothing, but I can't seem to find the documentation. It's just
ignored.
- A final global function?
- Is that ref of void correct? (I think it is not)
- A enum of void function?
These are mysteries.
- What are global static variables in D?
variables evaluated at compile time, for example
int cfte_able_function() {
return 14423 + 12341;
}
int other_function() {
writeln(Not cfte);
return 7;
}
static x1 = 123; //works
static x2 = cfte_able_function; //works;
static x3 = other_function; //cannot evaluate other_function() at
compile time
As you say, these are odd issues indeed. :)
Re: Tidy attributes
Pelle M.
static does not apply to free functions, I would guess this means the
same as auto.
As far as I know a global function like:
auto foo() {}
is correct in D2, it means the compiler will infer the return type, that here
is void. That's why I have not added this case to that list.
static here means 'known at compile time', I think.
As far as I know, it's enum that has that purpose.
As you say, these are odd issues indeed. :)
I'll wait for more answers, and then I'll add to Bugzilla. Java is not the
language I prefer, but I like a lot the strictness of its compiler, it makes
sure your attributes are all correct and meaningful. This avoids bugs and do
helps newbies learn the language in less time.
Thank you for your answers,
bearophile
Re: Tidy attributes
On 03/11/2010 10:44 PM, bearophile wrote: As far as I know, it's enum that has that purpose. Oh, but they are not the same. enum declares a constant, whereas static declares a variable. A static global is still mutable. Thank you for your answers, bearophile Why thank you!
Re: Tidy attributes
Filed it, with some small changes: http://d.puremagic.com/issues/show_bug.cgi?id=3934 Bye, bearophile
Re: Static attributes aren' immutable
div0: Yeah, I *never* access static vars through an instance, I always use the class name. Somebody want to post in the main group? It seems there are few people that agree with you, but Walter has not answered about this yet, so you can ask him his opinion. I like to use a tidy language. Bye, bearophile
Re: Static attributes aren' immutable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
bearophile wrote:
I'm playing some more with immutables in D2. This program compiles:
struct Foo {
static int x;
}
void main() {
immutable Foo f;
Foo.x++;
f.x++;
}
Is this code supposed to be correct? If I have an immutable struct I want all
of it to be immutable...
Bye and thank you,
bearophile
Yes it's correct.
x is really just a global variable, or a thread local variable if you
are using a newer compiler.
putting it in Foo simply puts it in a namespace.
You could argue that 'f.x++' should not be allowed
in order to emphasis that x is not part of an instance,
but that could make writing generic code more awkward.
IIRC, you can do:
immutable struct Foo {
static int x;
}
Then you can't write to x, but then you can't ever
write to any instance members either.
- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLkRj0T9LetA9XoXwRAs+kAJ9ClMvkpPtODmsjcE1RudT+5rucEACgsPma
yaNYtgO64gs+vYeEA0MfDTc=
=wq60
-END PGP SIGNATURE-
Re: Static attributes aren' immutable
bearophile wrote:
I'm playing some more with immutables in D2. This program compiles:
struct Foo {
static int x;
}
void main() {
immutable Foo f;
Foo.x++;
f.x++;
}
Is this code supposed to be correct? If I have an immutable struct I want all
of it to be immutable...
Bye and thank you,
bearophile
It is correct, because x isn't a part of the struct, it's a global
variable. However, in my opinion that last line should cause a compiler
error -- it shouldn't be possible to access static members through an
instance of the struct.
-Lars
Re: Static attributes aren' immutable
div0: putting it in Foo simply puts it in a namespace. So my (wrong) idea of immutable applied to a struct was that every thing in such namespace becomes immutable (I think this is a bit more intuitive). What do you think of modifying D2 so in a situation like the one I've shown even static arguments become const/immutable? Can this cause troubles to other things? Thank you to you and Lars T. Kyllingstad for the answers. Bye, bearophile
Re: Static attributes aren' immutable
On 03/05/2010 07:50 PM, bearophile wrote: div0: putting it in Foo simply puts it in a namespace. So my (wrong) idea of immutable applied to a struct was that every thing in such namespace becomes immutable (I think this is a bit more intuitive). What do you think of modifying D2 so in a situation like the one I've shown even static arguments become const/immutable? Can this cause troubles to other things? Thank you to you and Lars T. Kyllingstad for the answers. Bye, bearophile Immutability (somewhat) guarantees the value will never ever change. The static attribute could be changed by a non-immutable instance, and can therefore not be immutable. It could be const for the immutable instance, but I don't see the gains from it. I do, however, see the gains from not being able to access the static members through an instance.
Re: Static attributes aren' immutable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pelle Månsson wrote: On 03/05/2010 07:50 PM, bearophile wrote: div0: putting it in Foo simply puts it in a namespace. So my (wrong) idea of immutable applied to a struct was that every thing in such namespace becomes immutable (I think this is a bit more intuitive). What do you think of modifying D2 so in a situation like the one I've shown even static arguments become const/immutable? Can this cause troubles to other things? Thank you to you and Lars T. Kyllingstad for the answers. Bye, bearophile Immutability (somewhat) guarantees the value will never ever change. The static attribute could be changed by a non-immutable instance, and can therefore not be immutable. It could be const for the immutable instance, but I don't see the gains from it. I do, however, see the gains from not being able to access the static members through an instance. Yeah, I *never* access static vars through an instance, I always use the class name. Somebody want to post in the main group? Might be worth a bigger discussion; perhaps somebody can provide a good use case for access through an instance we're not seeing. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLkWUuT9LetA9XoXwRAjTIAJ9kwfo1mKj4J7ghW+SoEYqMBDu/pACfaJyf YAfV9JMHUAUfsFWw3e5pTSg= =/Sfv -END PGP SIGNATURE-
Re: Static attributes aren' immutable
div0: Somebody want to post in the main group? OK, I'll do it soon :-) Bye, bearophile
