Re: if (int bar = .. bug or some thing
On Tuesday, 31 October 2017 at 04:27:27 UTC, Joel wrote:
Ok, thanks guys.
why not throw in some UFCS too...just because you can ;-)
import std.stdio;
void main()
{
int foo;
if (foo.bar != 0) // would be nice if I could do: (int
foo.bar != 0)
{
throw new Exception("foo.bar != 0");
}
}
auto bar(int x,)
{
return -10;
}
Re: if (int bar = .. bug or some thing
Ok, thanks guys.
Re: if (int bar = .. bug or some thing
On Tuesday, 31 October 2017 at 04:08:12 UTC, Joel wrote:
if (int bar = foo() != 0) {
Not a bug, but I do think it is an iffy design.
That is more like:
int bar;
if(bar = (foo() != 0))
so the foo != 0 is evaluated first, which ends up being boolean
true or false, then THAT true/false value is converted to int and
assigned to bar, hence it becomes 0 or 1.
You can't really combine declaration and non-trivial comparison
in a single statement.
Re: if (int bar = .. bug or some thing
On Tuesday, October 31, 2017 04:08:12 Joel via Digitalmars-d-learn wrote:
> The following code assert fails (bar == 1, not -10!). I've wasted
> a bit of time because of this happening.
>
> void main() {
> if (int bar = foo() != 0) {
> assert(bar == -10);
> }
> }
>
> auto foo() {
> return -10;
> }
Why would you expect it to be -10? bar is assigned the result of foo() != 0,
which is a boolean result and will be either true or false. When that's
assigned to int, a conversion occurs, and that conversion treats true as 1
and false as 0. If you want the result to be -10, then you need to assign
the result of foo() to bar, not the result of foo() != 0. Now, because 0 is
treated as false, you could probably still do
if(int bar = foo())
rather than something like
int bar = foo();
if(bar != 0)
but regardless, the result of foo() != 0 is going to be bool, not int, so
all you'll ever get out of it is true or false, which will then be 1 or 0 if
converted to int.
- Jonathan M Davis
if (int bar = .. bug or some thing
The following code assert fails (bar == 1, not -10!). I've wasted
a bit of time because of this happening.
void main() {
if (int bar = foo() != 0) {
assert(bar == -10);
}
}
auto foo() {
return -10;
}
Re: using .init reliably
On 10/30/17 11:39 AM, Alex wrote:
On Monday, 30 October 2017 at 15:03:25 UTC, Steven Schveighoffer wrote:
This should also be disallowed. In order to know x.init means what it
normally means, we shouldn't allow overriding it. This is the point of
this thread, and the impetus for renaming of TypeInfo.init().
Yeah... my problem is, that I don't know it at compile time.
You know it at language time :)
The .init property is provided by the compiler, unless you define it.
It means the default value of the type.
I had something different in mind:
Either the "init" property belongs to the semantic of a type (in this
case a struct) or it doesn't.
It belongs to the language. The init property should be only allowed by
the language. It doesn't need to be a keyword, but it should not be
allowed as a member function or field.
If it does (I think, this is the case at this time point), then it
should be overloadable. However, restrictions can be applied, like "one
cannot override the standard (i. e. empty) provided interface".
If it does not, then, an overload, like I did should not be handled
differently like every other overload, and the exception in my example
would be a bug.
It should not be overridable. Otherwise, we cannot reason about
low-level concepts that build types from scratch.
Once you override the property, the compiler will always use that. You
can't override a name and then have it fall back on the default name
for a different overload. D is very careful to resolve symbol names in
an unambiguous way.
Ok, I'm sorry for the confusion :)
My question was:
While I'm agreeing, that the init property should not be overridden,
could it be overloaded (with another interface)? And why if not? As
different interfaces fully disambiguate names...
No, it shouldn't be overridden. Why not? Because so much generic code
assumes that T.init or t.init (instance t of type T) means "the
compile-time defined initializer for type T", and to allow any
overriding of this would be hugely damaging to such functions.
Yes, I understand that you want to not override the getter init
property, but simply choose another name for your function, and it
should work just fine. I recommend "initializer" or "initialize" or "make".
What you can do is simply rename the static method. Certainly a valid
route to have a method to initialize the type variables.
So, using another interface is not the same, as using another name? Or
is the init property handled differently? ;)
In D, when you have overloads at different levels of priority, it
doesn't matter. Whatever has the highest priority owns all the overloads.
For instance:
struct S
{
void foo(int x) {...}
}
void foo(S s, string x) {...}
void main()
{
S s;
s.foo("hi"); // error
}
My contention is that the language definition of init should have the
highest priority.
FYI: https://issues.dlang.org/show_bug.cgi?id=17954
-Steve
Re: CSV with empty values for integer fields
On Sunday, 29 October 2017 at 15:45:23 UTC, Jesse Phillips wrote: Not really you'll need to parse it out as a string and do the conversion later. It probably would be good to support nullable!int pretty sure it doesn't currently. Should I raise a ticket on Bugzilla to address this?
Re: using .init reliably
On Monday, 30 October 2017 at 15:03:25 UTC, Steven Schveighoffer wrote: This should also be disallowed. In order to know x.init means what it normally means, we shouldn't allow overriding it. This is the point of this thread, and the impetus for renaming of TypeInfo.init(). Yeah... my problem is, that I don't know it at compile time. The .init property is provided by the compiler, unless you define it. It means the default value of the type. I had something different in mind: Either the "init" property belongs to the semantic of a type (in this case a struct) or it doesn't. If it does (I think, this is the case at this time point), then it should be overloadable. However, restrictions can be applied, like "one cannot override the standard (i. e. empty) provided interface". If it does not, then, an overload, like I did should not be handled differently like every other overload, and the exception in my example would be a bug. 2. Regardless of the result of the first question, line 4 of the example yields an error, although I didn't touch the standard init property. Why? Once you override the property, the compiler will always use that. You can't override a name and then have it fall back on the default name for a different overload. D is very careful to resolve symbol names in an unambiguous way. Ok, I'm sorry for the confusion :) My question was: While I'm agreeing, that the init property should not be overridden, could it be overloaded (with another interface)? And why if not? As different interfaces fully disambiguate names... 3. A practical aspect: What I try to solve is a two-stage initialization of an object. I know, this should be avoided. In order to do this, I try to separate the initializations of the type and its objects. (By the way, is this the right way to go?) What you can do is simply rename the static method. Certainly a valid route to have a method to initialize the type variables. So, using another interface is not the same, as using another name? Or is the init property handled differently? ;) Note that the way you have it, 'first' is a thread-local variable, so it would have to be initialized in every thread. Yes, this is the intention. Thanks a lot :) Alex
Re: using .init reliably
On 10/30/17 6:59 AM, Alex wrote:
Sorry for dig out this posting, but this one is more recent, than
http://forum.dlang.org/thread/k15of5$22ub$1...@digitalmars.com?page=1
and my question is just beyond the two:
I'm with you, regarding that the standard init property should not be
overridden. But how about to override it with a custom init function,
which has a different interface?
An example:
/// --- code --- ///
void main()
{
int first = 5;
//auto s0 = S.init; // this line (4) yields an error:
// function app.S.init (int fParam) is not callable using
argument types ()
S.init(first);
int second = 2;
auto s = S(second);
assert(s.first == first);
assert(s.second == second);
}
struct S
{
static int first;
int second;
// I'm aware of the fact, that nobody should redefine init() like:
// static auto init() { writeln("oh-oh..."); }
static void init(int fParam) { first = fParam; }
This should also be disallowed. In order to know x.init means what it
normally means, we shouldn't allow overriding it. This is the point of
this thread, and the impetus for renaming of TypeInfo.init().
this(int sParam) { second = sParam; }
}
/// --- code --- ///
My question has some components:
1. If this also should be disallowed: why, as it could be possible, that
I'm not aware of existence of any init property of every struct.
The .init property is provided by the compiler, unless you define it. It
means the default value of the type.
2. Regardless of the result of the first question, line 4 of the example
yields an error, although I didn't touch the standard init property. Why?
Once you override the property, the compiler will always use that. You
can't override a name and then have it fall back on the default name for
a different overload. D is very careful to resolve symbol names in an
unambiguous way.
3. A practical aspect: What I try to solve is a two-stage initialization
of an object. I know, this should be avoided. In order to do this, I try
to separate the initializations of the type and its objects.
(By the way, is this the right way to go?)
What you can do is simply rename the static method. Certainly a valid
route to have a method to initialize the type variables.
Note that the way you have it, 'first' is a thread-local variable, so it
would have to be initialized in every thread.
Of course, I could use an external function, say
prepareType(S)(int fParam)
to do so, and this is the place, where I remembered the old posting and
found the current one.
Whether you put it inside the type or not is a preference. Either way is
fine. It just shouldn't be named init if it's a member.
As we are already beyond 2.075, are there known tickets about the
disabling of the ability to override the init property, where I can post
the bug of the second question, in case it is one?
Clearly, we have dropped the ball on deprecating this. Not sure if there
is a ticket on it. I'll make one for the time being. We should try
deprecating it by 2.078 (overriding init that is).
-Steve
Re: Associative arrays with keys containing mutable indirections
On 10/30/17 6:49 AM, Tony wrote: I prefer the built-in associative array over using some template library. It has the clean look and ease-of-use that you get with a similar data structure in dynamic languages like Python. I consider it a top feature of D. There is a misunderstanding here. The goal is to replace the implementation of the builtin AA with a template implementation. Right now there are some "magic" pieces of the AA that are helped by the compiler. If we can do this all in a template library, then the syntax doesn't change at all, but now you have better abilities to customize the builtin AAs, or use more specialized templates in some cases. -Steve
Re: using .init reliably
Sorry for dig out this posting, but this one is more recent, than
http://forum.dlang.org/thread/k15of5$22ub$1...@digitalmars.com?page=1
and my question is just beyond the two:
I'm with you, regarding that the standard init property should
not be overridden. But how about to override it with a custom
init function, which has a different interface?
An example:
/// --- code --- ///
void main()
{
int first = 5;
//auto s0 = S.init; // this line (4) yields an error:
// function app.S.init (int fParam) is not callable using
argument types ()
S.init(first);
int second = 2;
auto s = S(second);
assert(s.first == first);
assert(s.second == second);
}
struct S
{
static int first;
int second;
// I'm aware of the fact, that nobody should redefine init()
like:
// static auto init() { writeln("oh-oh..."); }
static void init(int fParam) { first = fParam; }
this(int sParam) { second = sParam; }
}
/// --- code --- ///
My question has some components:
1. If this also should be disallowed: why, as it could be
possible, that I'm not aware of existence of any init property of
every struct.
2. Regardless of the result of the first question, line 4 of the
example yields an error, although I didn't touch the standard
init property. Why?
3. A practical aspect: What I try to solve is a two-stage
initialization of an object. I know, this should be avoided. In
order to do this, I try to separate the initializations of the
type and its objects.
(By the way, is this the right way to go?)
Of course, I could use an external function, say
prepareType(S)(int fParam)
to do so, and this is the place, where I remembered the old
posting and found the current one.
As we are already beyond 2.075, are there known tickets about the
disabling of the ability to override the init property, where I
can post the bug of the second question, in case it is one?
4. The chipped in question in the previous paragraph :)
Re: Associative arrays with keys containing mutable indirections
I prefer the built-in associative array over using some template library. It has the clean look and ease-of-use that you get with a similar data structure in dynamic languages like Python. I consider it a top feature of D.
[std.regex] Set operations with unicode properties.
Greetings,
I need to match any character, except control characters and some
other exceptions and thought this would be a good usecase to use
character classes and set operations.
Can I combine this with unicode properties?, e.g: any Charactor
that is not a control character and not ';' or ':'?
---
string regex = "[\p{Any}--\p{Control}--[;:]]";
---
Is this possible somehow?
Thanks,
- Tobias
