Re: Confusion/trying to understand CTFE keywords
On Tuesday, June 05, 2018 22:08:32 Stefan Koch via Digitalmars-d-learn wrote: > On Tuesday, 5 June 2018 at 18:00:05 UTC, Steven Schveighoffer > > wrote: > > No, it's definitely a bug. main is not being evaluated at > > compile time. The real result of this function should be a > > compile-time error -- __ctfe is a *runtime* value that is > > always defined based on whether you are __ctfe or not. > > Therefore, n must be a runtime value, and not usable as a > > static array dimension. > > > > If the posted code is valid, then this should be valid as well: > > > > static if(__ctfe) > > > >immutable n = 1; > > > > else > > > >immutable n = 2; > > > > But it's not. > > > > -Steve > > I see what you mean. > I fear fixing this bug will not be easy without breaking arguably > valid uses. Any such case should work by either using an enum instead or using an enum to have the value during CTFE and then initialize a const or immutable variable with it. We'd likely need to deprecate the old behavior rather than simply fixing it in order to avoid breaking code, but the result would ultimately be cleaner, and it should be easy for any affected code to be updated. As is standsw the fact that immutable i = foo(); int[i] arr; works and uses CTFE whereas immutable i = foo(); doesn't do any CTFE just increases the confusion of how CTFE works. The fact that __ctfe then affects things further just makes matters worse. CTFE really should only kick in when it has to kick in. That way, it's clean and understandable as to when it kicks in and when it doesn't, and anyone who wants to initialize a local variable with CTFE can always just use an intermediary enum. We have too much confusion over when CTFE kicks in even without this quirk with immutable. - Jonathan M Davis
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 18:00:05 UTC, Steven Schveighoffer wrote: No, it's definitely a bug. main is not being evaluated at compile time. The real result of this function should be a compile-time error -- __ctfe is a *runtime* value that is always defined based on whether you are __ctfe or not. Therefore, n must be a runtime value, and not usable as a static array dimension. If the posted code is valid, then this should be valid as well: static if(__ctfe) immutable n = 1; else immutable n = 2; But it's not. -Steve I see what you mean. I fear fixing this bug will not be easy without breaking arguably valid uses.
Re: Orange serializer/deserializer
I'm also having some issue now when I changed a type from using a class to using it's base interface Unhandled exception: orange.serialization.SerializationException.SerializationException The object of the static type "const(ItemInterface)" have a different runtime type (Item) and therefore needs to either register its type or register a serializer for its type "Item". at ..\..\..\orange\serialization\SerializationException.d(25) Item inherits from ItemInterface. I was storing a list of Items and changed it to store ItemInterface Item[] -> ItemInterface[] and this is when the error happened. Of course, I'd expect the interface not being serializable(although, maybe @properties should be?) it would be nice if it would store the actual type in it's place(an Item). Else, this prevents me from using interfaces.
Re: Confusion/trying to understand CTFE keywords
On 6/5/18 12:10 PM, Stefan Koch wrote: This is not bug just not very intuitive. Since you are declaring a static array the value of n needs to known at compiletime. so it'll try to evaluate n at an compile-time context in which n is 1. however when code-generation for the function is done __ctfe will be false. Causing the n variable to be initialized to 2. Therefore n will not be equal to a.length. No, it's definitely a bug. main is not being evaluated at compile time. The real result of this function should be a compile-time error -- __ctfe is a *runtime* value that is always defined based on whether you are __ctfe or not. Therefore, n must be a runtime value, and not usable as a static array dimension. If the posted code is valid, then this should be valid as well: static if(__ctfe) immutable n = 1; else immutable n = 2; But it's not. -Steve
Re: Orange serializer/deserializer
On Saturday, 2 June 2018 at 20:11:17 UTC, Jacob Carlborg wrote: On 2018-06-02 03:30, IntegratedDimensions wrote: How can I modify the pre serialization and post serialization values? I need to transform some variables that are stored but I would like to do this easily "inline"(would be cool to be able to provide a delegate to do the transformations at the site of definition of the fields). Use the "onSerializing" and "onSerialized" UDAs on a method. "onSerializing" will be called before serializing and "onSerialized" after serializing. Have a look at the unit tests [1]. Also, how does orange handle properties? Seems it just deals with fields and ignores all functions(does not use getter and setter of properties). This is valid, of course, just want to make sure. I still need to be able to transform values pre and post though. That is correct, it only (de)serializes fields. If you want to (de)serialize proprieties, implement the "toData" and "fromData". See the example in the wiki [2]. Note, by implementing these methods none of the standard serialization will occur. If you want to serialize the fields as well, you need to do that as well when implementing "toData" and "fromData". It's also possible to implement these "methods" in a non-intrusive way, i.e. for customizing serialization of third party type [3]. [1] https://github.com/jacob-carlborg/orange/blob/master/tests/Events.d#L39-L54 [2] https://github.com/jacob-carlborg/orange/wiki/Custom-Serialization [3] https://github.com/jacob-carlborg/orange/blob/master/tests/NonIntrusive.d Thanks. I'm having problems preventing void* pointers from not being serialized ..\..\..\orange\serialization\Serializer.d(975): Error: expression `*value` is `void` and has no value ..\..\..\orange\serialization\Serializer.d(1491): Error: new can only create structs, dynamic arrays or class objects, not `void`'s and all I've added to my class is @nonSerialized void* ptr; It seems that the (de)serializer should just ignore all void's no matter what. They can't be serialized to any meaningful thing. Maybe spit a warning out if the uda is not added. Usually pointer values are not meant to be serialized anyways.
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 13:27:35 UTC, Steven Schveighoffer
wrote:
On 6/5/18 6:40 AM, Simen Kjærås wrote:
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot
be read at compile time' error. The fact that n is immutable
shouldn't be enough to use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
Indeed it is a bug. Interesting to see what the compiler sees
as its AST:
import object;
void main()
{
immutable immutable(int) n = __ctfe ? 1 : 2;
int[1] a = 0;
assert(1LU == cast(ulong)n);
return 0;
}
This is what -vcg-ast spits out.
Note the int[1].
-Steve
This is not bug just not very intuitive.
Since you are declaring a static array the value of n needs to
known at compiletime.
so it'll try to evaluate n at an compile-time context in which n
is 1.
however when code-generation for the function is done __ctfe will
be false.
Causing the n variable to be initialized to 2.
Therefore n will not be equal to a.length.
Re: determining if array element is null
On Tuesday, 5 June 2018 at 14:52:28 UTC, Timoses wrote: Does `int[4] nums = void` work? Work for what? If you avoid initialization, then the variable(s) are not initialized. https://dlang.org/spec/declaration.html#void_init However, an int is not nullable and always contains a value.
Re: determining if array element is null
On Saturday, 2 June 2018 at 18:10:38 UTC, eastanon wrote:
Does D array implementation support an array of null values?
int a[4] = null;
But I ran into a type error while checking if a[i] is null
foreach(i; 0..3){
if(i == null){
writeln("it is null");
}
}
}
How do you set fixed size array of null values and check if
they are null?
Does `int[4] nums = void` work?
Re: Confusion/trying to understand CTFE keywords
On 6/5/18 6:40 AM, Simen Kjærås wrote:
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot be read at
compile time' error. The fact that n is immutable shouldn't be enough to
use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
Indeed it is a bug. Interesting to see what the compiler sees as its AST:
import object;
void main()
{
immutable immutable(int) n = __ctfe ? 1 : 2;
int[1] a = 0;
assert(1LU == cast(ulong)n);
return 0;
}
This is what -vcg-ast spits out.
Note the int[1].
-Steve
Re: Confusion/trying to understand CTFE keywords
On Tuesday, June 05, 2018 11:18:05 Gopan via Digitalmars-d-learn wrote:
> On Tuesday, 5 June 2018 at 10:40:20 UTC, Simen Kjærås wrote:
> > On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
> >> void main()
> >> {
> >>
> >> immutable n = __ctfe ? 1 : 2;
> >> int[n] a;
> >> assert(a.length == n); // fails, wat
> >>
> >> }
> >
> > That's gotta be a bug - that should give a 'variable n cannot
> > be read at compile time' error. The fact that n is immutable
> > shouldn't be enough to use it at compile time. Filed as
> > https://issues.dlang.org/show_bug.cgi?id=18945.
> >
> > --
> >
> > Simen
>
> Not only immutable. The behavior is same if you declare n as
> 'const int' also.
It's a bug either way. I suspect that someone made it work as an enhancement
request at some point on the theory that the variable was guaranteed to
always be the same, and they didn't take __ctfe into account. Regardless,
initializing a non-static, local variable shouldn't be triggering CTFE.
- Jonathan M Davis
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 10:40:20 UTC, Simen Kjærås wrote:
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot
be read at compile time' error. The fact that n is immutable
shouldn't be enough to use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
--
Simen
Not only immutable. The behavior is same if you declare n as
'const int' also.
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot be
read at compile time' error. The fact that n is immutable
shouldn't be enough to use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
--
Simen
Re: Confusion/trying to understand CTFE keywords
On Sunday, 3 June 2018 at 21:32:06 UTC, gdelazzari wrote:
Couldn't a keyword like "ctfe" (just making it up right now)
exist? So that, when seeing something like
ctfe myNumber = 5;
ctfe if (myNumber + 2 == 7)
{
// ...
}
one could immediately understand that the code is
executed/evaluated at compile time. True, after someone knows
that "static" and "enum" mean (in the above example) that some
compile-time things are happening, it's fine. I just find it a
bit confusing not having a dedicated keyword but re-using
existing ones that also serve other purposes...
Hi gdelazzari,
While seeing your post, I just recollected my post 4 years ago.
https://forum.dlang.org/post/wbfnvwulchrpnrxov...@forum.dlang.org
I recommend you to go through it. Let me put here my thoughts
again.
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
Here, the declaration int[n] a forces n to be calculated during
compile time. During compile time, __ctfe is true (I dont know
if it a variable or macro, etc). Hence the value of n during
compile time is 1. So, size of the array a is 1. Anyway, n is
calculated during runtime too. At runtime, __ctfe is false. n
becomes 2. Finally, at runtime a.length is 1 and n is 2.
This shocked me. ie While reading a huge code, you need to check
how you got the value of n, which I personally dont want to.
While this scared me away, I thought about it. What is the
underlying problem? My immediate answer is that the same
variable getting computed during both compile time and runtime
caused this issue. Why should a variable get a new value at
runtime if it has already got a value during compile time, for
the same statement?
May be I am less imaginative. I still wish some could enlighten
me to accept this behavior if everybody else thinks it is right.
Regards,
Gopan
Re: Line endings when redirecting output to file on windows.
On Monday, 4 June 2018 at 15:31:04 UTC, Steven Schveighoffer wrote: Windows C library has this bizarro mode for FILE * called "text" mode, which is the default. In this mode, it scans all output, and anywhere it sees a '\n', it replaces it with "\r\n". Thanks, Steven.
