Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 21:38:27 UTC, Walter Bright wrote: On 11/12/2018 8:28 AM, 12345swordy wrote: The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. The exact same thing happens when there are both int and short overloads. The underlying issue is is bool a one bit integer type, or something special? D defines it as a one bit integer type, fitting it into the other integer types using exactly the same rules. If it is to be a special type with special rules, what about the other integer types? D has a lot of basic types :-) You nailed it on the head. The only sensible course of action, therefore, is to give programmers the option to disable implicit conversions, completely (or if doable, more precisely). And while you're thinking about how to do that, can you also please think about how to give the programmer the option to enforce privacy on variable/method within a module. Programmers just want to be able to write code that is more likely to be correct, than not, and have the compiler catch it when it's not. You want to attract such programmers, or not?
Re: NES emulator written in D
On Tuesday, 13 November 2018 at 05:59:52 UTC, Manu wrote:
Nice work.
Oh wow, this is pretty rough!
```
void createTable() {
this.table = [
, , , , ,
,
, , , , ,
,
, , , ,
...
```
Here's one I prepared earlier:
https://github.com/TurkeyMan/superemu (probably doesn't work
with DMD from the last year or 2!) Extensible architecture,
supports a bunch of systems.
That's an artifact from the original code which was written in
Go. My main focus was adding missing instructions & fixing any
timing issues. It now passes nearly every NES specific CPU
instruction & timing test I can throw at it so I'm fairly happy
with it. Any improvements are always welcome though.
Re: NES emulator written in D
On Sat, Feb 3, 2018 at 5:55 AM blahness via Digitalmars-d-announce
wrote:
>
> Hi everyone,
>
> Not sure how interested people here will be with this but I've
> ported https://github.com/fogleman/nes from Go to D [1]. I should
> point out that I'm not the author of the original Go version.
>
> The emulator code itself is 100% D with no dependencies. I've
> also created a little app using SDL to show how you'd put this
> library to use [2].
>
> Its PPU & APU timing isn't 100% accurate (same as the Go version)
> so not all games will work correctly but this should be pretty
> easy to fix.
>
> Links
> --
> [1] https://github.com/blahness/nes
> [2] https://github.com/blahness/nes_test
Nice work.
Oh wow, this is pretty rough!
```
void createTable() {
this.table = [
, , , , , ,
, , , , , ,
, , , ,
...
```
Here's one I prepared earlier: https://github.com/TurkeyMan/superemu
(probably doesn't work with DMD from the last year or 2!)
Extensible architecture, supports a bunch of systems.
Re: NES emulator written in D
On Saturday, 3 February 2018 at 13:52:17 UTC, blahness wrote: Hi everyone, Not sure how interested people here will be with this but I've ported https://github.com/fogleman/nes from Go to D [1]. I should point out that I'm not the author of the original Go version. The emulator code itself is 100% D with no dependencies. I've also created a little app using SDL to show how you'd put this library to use [2]. Its PPU & APU timing isn't 100% accurate (same as the Go version) so not all games will work correctly but this should be pretty easy to fix. Links -- [1] https://github.com/blahness/nes [2] https://github.com/blahness/nes_test Just to let anyone interested in this know it's been updated. The APU (sound) is much improved as is the overall cycle accuracy. It now passes several hundred accuracy tests (about halfway there). Most of the work left to do involves improving the PPU (video) which really hasn't been touched much since the original port. If you want to see it in action the best thing to do is grab & build nes_test or if you're using Windows you can download the newest binary release from https://github.com/blahness/nes_test/releases. The first version was a straight port but it's diverged a good amount by this point.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Tue, Nov 13, 2018 at 02:12:30AM +, 12345swordy via
Digitalmars-d-announce wrote:
> On Monday, 12 November 2018 at 21:38:27 UTC, Walter Bright wrote:
[...]
> > The underlying issue is is bool a one bit integer type, or something
> > special? D defines it as a one bit integer type, fitting it into the
> > other integer types using exactly the same rules.
> >
> > If it is to be a special type with special rules, what about the
> > other integer types? D has a lot of basic types :-)
>
> Ok, you don't want to introduce special rules for integers, and that
> understandable.
>
> However there needs be a tool for the programmer to prevent unwanted
> implicit conversation when it comes to other users passing values to
> their public overload functions.(Unless there is already a zero cost
> abstraction that we are not aware of).
[...]
This discussion makes me want to create a custom bool type that does not
allow implicit conversion. Something like:
struct Boolean {
private bool impl;
static Boolean True = Boolean(1);
static Boolean False = Boolean(0);
// For if(Boolean b)
opCast(T : bool)() { return impl; }
...
}
Unfortunately, it wouldn't quite work because there's no way for
built-in comparisons to convert to Boolean instead of bool. So you'd
have to manually surround everything with Boolean(...), which is a
severe usability handicap.
T
--
People tell me that I'm skeptical, but I don't believe them.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 21:38:27 UTC, Walter Bright wrote: On 11/12/2018 8:28 AM, 12345swordy wrote: The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. The exact same thing happens when there are both int and short overloads. The underlying issue is is bool a one bit integer type, or something special? D defines it as a one bit integer type, fitting it into the other integer types using exactly the same rules. If it is to be a special type with special rules, what about the other integer types? D has a lot of basic types :-) Ok, you don't want to introduce special rules for integers, and that understandable. However there needs be a tool for the programmer to prevent unwanted implicit conversation when it comes to other users passing values to their public overload functions.(Unless there is already a zero cost abstraction that we are not aware of). -Alex
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Tue, 13 Nov 2018 00:28:46 +, Isaac S. wrote: > Sorry if it wasn't clear, I meant that if `enum Foo : some_int_type` > makes it so some_int_type is preferred (because it's a more direct > conversion) DScanner could warn anyone that just does `enum Foo`. Sorry, I read too hastily and thought you meant relative to the status quo.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Tuesday, 13 November 2018 at 00:21:25 UTC, Neia Neutuladh wrote: On Tue, 13 Nov 2018 00:08:04 +, Isaac S. wrote: If you really want this plaque in the language, at least make it not affect those that gave their enum a type. If you at least do that, someone can add it to DScanner to tell anyone that doesn't type their enum to expect illogical behavior. Unfortunately, dscanner only parses code. It can't tell you that your overload resolution depends on value range propagation on an enum value; that depends on semantic analysis. So it would have to aggressively warn you against using `enum Foo : some_int_type`. Sorry if it wasn't clear, I meant that if `enum Foo : some_int_type` makes it so some_int_type is preferred (because it's a more direct conversion) DScanner could warn anyone that just does `enum Foo`.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Tue, 13 Nov 2018 00:08:04 +, Isaac S. wrote: > If you really want this plaque in the language, at least make it not > affect those that gave their enum a type. If you at least do that, > someone can add it to DScanner to tell anyone that doesn't type their > enum to expect illogical behavior. Unfortunately, dscanner only parses code. It can't tell you that your overload resolution depends on value range propagation on an enum value; that depends on semantic analysis. So it would have to aggressively warn you against using `enum Foo : some_int_type`.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Mon, 12 Nov 2018 14:07:39 -0800, Walter Bright wrote: > => conversion> >=> conversion> One confusion is from value range propagation / constant folding reaching past the static type information to yield a different result from what static typing alone would suggest. My intuition was that the compiler should prefer the declared type of the symbol when it's got a symbol with a declared type. Like, A implicitly converts to int, and int doesn't implicitly convert to short, so an expression of type A shouldn't implicitly convert to short. And this is *generally* true, but when the compiler can use constant folding to get a literal value out of the expression, it does things I don't expect. And this doesn't happen with structs with alias this, but I can't tell if that's an oversight or not, and there's no doubt some nuanced explanation of how things work, and it probably solves some edge cases to have it work differently...
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
*snip*
Both f(int) and f(short) match, because implicit conversions
rank the same.
To disambiguate, f(short) is pitted against f(int) using
partial ordering rules,
which are:
Can a short be used to call f(int)? Yes.
Can an int be used to call f(short)? No.
So f(short) is selected, because the "Most Specialized"
function is selected
when there is an ambiguous match.
Note: the "most specialized" partial ordering rules are
independent of the arguments being passed.
Well frankly that's bad design. If I declare Foo as an int enum I
(and any _reasonable_ programmer) would expect Foo to prefer the
int overload.
Think of it this way, each enum can be thought of like this:
immutable struct EnumName(T) {
T value;
alias value this;
}
So, if a programmer declares an enum of type int (EnumName!int),
the alias-this will convert the enum to an int. Thus, the
programmer expects the value to implicitly
convert to an int; which is a _direct_ implicit conversion (IE:
is weighed heavier than just an implicit conversion).
Regardless of what you believe, it is an inconsistent behavior to
the programmer (IE: The person you should be considering as a
language designer).
If this horrid design choice stays, this _will_ go down as a
mistaken "feature" of the language that everyone has to account
for otherwise it bites them (Example: C++ implicitly converting
by default instead of requiring an implicit attribute).
If you really want this plaque in the language, at least make it
not affect those that gave their enum a type. If you at least do
that, someone can add it to DScanner to tell anyone that doesn't
type their enum to expect illogical behavior.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 21:29:20 UTC, Walter Bright wrote: *snip* In my college daze I was learning programming alongside designing and building digital circuits, and later software for FPGAs and PLDs (ABEL). The notions of True, T, 1, !0 (from C and Asm), and +5V are all completely interchangeable in my mind. *snip* Well if we're talking about code smell: I would regard any code that expects true to be the same as 1 a code smell (I've interacted with C++ code that uses integers instead of bools and it's annoying and hard to read). There's a reason I use const foo = boolValue ? otherValue : 0; and not const foo = otherValue * boolValue; because it shows _intent_. I think the rest of us would like to hear an actual justification for bool being an "integer" type.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On 11/12/2018 1:39 PM, 12345swordy wrote: OK, I got to know what language you were using at the time, because I am curious at what other oddities does it have. I wish I could remember what it was. It was like 40 years ago :-)
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On 11/12/2018 12:34 PM, Neia Neutuladh wrote:
Tell me more about this "consistency".
int f(short s) { return 1; }
int f(int i) { return 2; }
enum : int { a = 0 }
enum A : int { a = 0 }
pragma (msg, f(a)); // calls f(int)
pragma (msg, f(A.a)); // calls f(short)
I.e. it's consistent.
Here's how it works:
f(a): `a` is a manifest constant of type `int`, and `int` is an exact match for
f(int), and f(short) requires an implicit conversion. The exact match of f(int)
is better.
f(A.a): `a` is an enum of type `A`. `A` gets implicitly converted to `int`. The
`int` then gets exact match to f(int), and an implicit match to f(short). The
sequence of conversions is folded into one according to:
=>
=>
Both f(int) and f(short) match, because implicit conversions rank the same. To
disambiguate, f(short) is pitted against f(int) using partial ordering rules,
which are:
Can a short be used to call f(int)? Yes.
Can an int be used to call f(short)? No.
So f(short) is selected, because the "Most Specialized" function is selected
when there is an ambiguous match.
Note: the "most specialized" partial ordering rules are independent of the
arguments being passed.
---
One could have be treated as "better than"
, and it sounds like a good idea, but
even C++, not known for simplicity, tried that and had to abandon it as nobody
could figure it out once the code examples got beyond trivial examples.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On 11/12/2018 11:28 AM, Adam D. Ruppe wrote: D used to have a `bit` type, wy back in the day. It was renamed to `bool` way back in D 0.148, released Feb 25, 2006. D's old bit type was not a bool. It literally was a single bit, and an array of bits was packed into an int by the compiler. It was abandoned because it caused more or less ugly problems with the type system, i.e. a required a phat pointer to represent it. A bit type is far better done as a library type.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On 11/12/2018 8:28 AM, 12345swordy wrote: The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. The exact same thing happens when there are both int and short overloads. The underlying issue is is bool a one bit integer type, or something special? D defines it as a one bit integer type, fitting it into the other integer types using exactly the same rules. If it is to be a special type with special rules, what about the other integer types? D has a lot of basic types :-)
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 21:29:20 UTC, Walter Bright wrote: I once worked with software that defined true as 0 and false as 1 OK, I got to know what language you were using at the time, because I am curious at what other oddities does it have. -Alex
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On 11/12/2018 2:05 AM, Jonathan M Davis wrote: *sigh* Well, I guess that's the core issue right there. A lot of us would strongly disagree with the idea that bool is an integral type and consider code that treats it as such as inviting bugs. In my college daze I was learning programming alongside designing and building digital circuits, and later software for FPGAs and PLDs (ABEL). The notions of True, T, 1, !0 (from C and Asm), and +5V are all completely interchangeable in my mind. I once worked with software that defined true as 0 and false as 1, and it was like being in London where all your intuition about cars is wrong. (I'd look to the left when stepping into the street, just to get nearly smacked by a car coming from the right.)
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Mon, 12 Nov 2018 20:34:11 +, Neia Neutuladh wrote:
> enum : int { a = 0 }
> enum A : int { a = 0 }
> f(a); // calls the int overload f(A.a); // calls the bool overload
>
> Tell me more about this "consistency".
Filed issue 19394. (Sorry for spam.)
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Mon, 12 Nov 2018 09:45:14 +, Mike Parker wrote:
> From Example B in the DIP:
>
> ```
> int f(bool b) { return 1; }
> int f(int i) { return 2; }
>
> enum E : int {
> a = 0,
> b = 1,
> c = 2,
> }
> ```
>
> Here, f(a) and f(b) call the bool overload, while f(c) calls the int
> version. This works because D selects the overload with the tightest
> conversion. This behavior is consistent across all integral types.
enum : int { a = 0 }
enum A : int { a = 0 }
f(a); // calls the int overload
f(A.a); // calls the bool overload
Tell me more about this "consistency".
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Mon, 12 Nov 2018 14:10:42 -0500, Steven Schveighoffer wrote: > But it's not consistent: And std.traits.isIntegral has not considered bools integral since its initial creation in 2007. Both Walter and Andrei have mucked about with that code and saw no reason to change it, even in wild and lawless days without deprecation cycles or DIPs. Andrei added a doc comment to explicitly note that bools and character types aren't considered integral back in 2009.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 18:25:22 UTC, Bastiaan Veelo wrote: I can’t say I have a strong opinion on this, but possibly it would be right to have an integral “bit” type to differentiate it from the Boolean type, just like we have a “byte” type to differentiate it from “char”... D used to have a `bit` type, wy back in the day. It was renamed to `bool` way back in D 0.148, released Feb 25, 2006. And BTW D 0.149 includes this under the bugs fixed section: "Implicit casts of non-bool to bool disallowed". What happened since then?
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On 11/12/18 4:45 AM, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from integer
and character literals to bool, has been rejected, primarily on the
grounds that it is factually incorrect in treating bool as a type
distinct from other integral types.
The TL;DR is that the DIP is trying to change behavior that is working
as intended.
From Example A in the DIP:
bool b = 1;
This works because bool is a "small integral" with a range of 0..1. The
current behavior is consistent with all other integrals.
But it's not consistent:
void isItAnInteger(T, bool makeCompile = false)() // works for all integers
{
T val = T.min; // I was surprised these work for bool
val = T.max;
static if(!makeCompile)
{
long x = -val; // Error: operation not allowed on bool b
++val; // Error: operation not allowed on bool val += 1
val += 1; // same error
}
val = cast(T)(T.max + 1);
assert(val == val.min); // error for bool, true + 1 == 2, but
cast(bool)2 truncates to true, not false.
}
void main()
{
import std.meta;
static foreach(T; AliasSeq!(int, uint, long, ulong, short, ushort,
byte, ubyte))
{
isItAnInteger!T();
}
// switch second parameter to false to see compiler errors.
isItAnInteger!(bool, true)();
}
If you have the makeCompile flag set to true, then it asserts for bool,
but nothing else.
-Steve
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 17:49:55 UTC, Joakim wrote: […] it's quite simple: they view a bool as an integral type with two possible values, a `bit` if you like. As such, they prefer to fit it into the existing scheme for integral types rather than special-casing booleans as Mike proposed. I can’t say I have a strong opinion on this, but possibly it would be right to have an integral “bit” type to differentiate it from the Boolean type, just like we have a “byte” type to differentiate it from “char”...
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 17:25:15 UTC, Johannes Loher wrote: On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote: Walter and Andrei take the position that this is incorrect the wrong way to view a bool. Unfortunately you did not include their justification for this position (if any). To me it would be interesting to know about the reasoning that is behind this position. Maybe you didn't read the link to their reasoning in the DIP, but it's quite simple: they view a bool as an integral type with two possible values, a `bit` if you like. As such, they prefer to fit it into the existing scheme for integral types rather than special-casing booleans as Mike proposed.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 17:25:15 UTC, Johannes Loher wrote: On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote: Walter and Andrei take the position that this is incorrect the wrong way to view a bool. Unfortunately you did not include their justification for this position (if any). To me it would be interesting to know about the reasoning that is behind this position. Everything I know is in the summary at the bottom of the DIP.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote: Walter and Andrei take the position that this is incorrect the wrong way to view a bool. Unfortunately you did not include their justification for this position (if any). To me it would be interesting to know about the reasoning that is behind this position.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 15:15:17 UTC, M.M. wrote: On Monday, 12 November 2018 at 15:03:08 UTC, Adam D. Ruppe wrote: On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote: The TL;DR is that the DIP is trying to change behavior that is working as intended. I thought the whole point of a DIP is to change behavior that is working as intended. Otherwise, we have a bug fix rather than a language change. +1 Let's not get hung up on my apparently poor choice of words for an informal summary in a newsgroup post. The more formal summary I appended to the DIP is closer to what they actually said. The DIP starts from the assumption that bool should be a distinct type from integrals, a point of view that is not uncommon. Walter and Andrei take the position that this is incorrect the wrong way to view a bool.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote: On Monday, November 12, 2018 2:45:14 AM MST Mike Parker via Digitalmars-d- announce wrote: DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool, has been rejected, primarily on the grounds that it is factually incorrect in treating bool as a type distinct from other integral types. *sigh* Well, I guess that's the core issue right there. A lot of us would strongly disagree with the idea that bool is an integral type and consider code that treats it as such as inviting bugs. We _want_ bool to be considered as being completely distinct from integer types. The fact that you can ever pass 0 or 1 to a function that accepts bool without a cast is a problem in and of itself. But it doesn't really surprise me that Walter doesn't agree on that point, since he's never agreed on that point, though I was hoping that this DIP was convincing enough, and its failure is certainly disappointing. - Jonathan M Davis The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. If we have a way of indicating that implicit conversions are not allowed, when passing values to functions then the issues that the DIP brought up is resolved. - Alex
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 15:03:08 UTC, Adam D. Ruppe wrote: On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote: The TL;DR is that the DIP is trying to change behavior that is working as intended. I thought the whole point of a DIP is to change behavior that is working as intended. Otherwise, we have a bug fix rather than a language change. +1
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote: The TL;DR is that the DIP is trying to change behavior that is working as intended. I thought the whole point of a DIP is to change behavior that is working as intended. Otherwise, we have a bug fix rather than a language change.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
That's strange, I thought polysemous literals prefer default type, not tightest type. --- auto b=1; static assert(is(typeof(b)==bool)); --- Error: static assert: is(int == bool) is false
Re: DMD backend now in D
On 13/11/2018 12:12 AM, Jacob Carlborg wrote: On 2018-11-12 03:37, Walter Bright wrote: On 11/11/2018 3:58 PM, Mike Franklin wrote: This is a significant milestone. Congratulations, Walter! Many people helped out with this, too. There are still a few .c files in https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's the significance of those? tk.c fp.c os.c strtold.c tk/mem.c These could be converted too, but are independent from everything else and hardly seem worth the bother. Sebastian has a PR for os.cd. dmd/root/ctfloat.d depends on the "strtold_dm" function defined in strtold.c [2] when compiling using Visual Studio. That means that the Dub package cannot be compile using Visual Studio without this file. [1] https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/root/ctfloat.d#L167-L170 [2] https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/backend/strtold.c#L138 That module needs a right rethink for dmd-fe as a library purposes. https://issues.dlang.org/show_bug.cgi?id=18810
Re: DMD backend now in D
On 2018-11-12 00:40, Walter Bright wrote: As: https://github.com/dlang/dmd/pull/8946 removes the header files for the old C++ code! BTW, this is great news :) -- /Jacob Carlborg
Re: DMD backend now in D
On 2018-11-12 03:37, Walter Bright wrote: On 11/11/2018 3:58 PM, Mike Franklin wrote: This is a significant milestone. Congratulations, Walter! Many people helped out with this, too. There are still a few .c files in https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's the significance of those? tk.c fp.c os.c strtold.c tk/mem.c These could be converted too, but are independent from everything else and hardly seem worth the bother. Sebastian has a PR for os.cd. dmd/root/ctfloat.d depends on the "strtold_dm" function defined in strtold.c [2] when compiling using Visual Studio. That means that the Dub package cannot be compile using Visual Studio without this file. [1] https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/root/ctfloat.d#L167-L170 [2] https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/backend/strtold.c#L138 -- /Jacob Carlborg
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On 2018-11-12 10:45, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from integer
and character literals to bool, has been rejected, primarily on the
grounds that it is factually incorrect in treating bool as a type
distinct from other integral types.
The TL;DR is that the DIP is trying to change behavior that is working
as intended.
From Example A in the DIP:
bool b = 1;
This works because bool is a "small integral" with a range of 0..1. The
current behavior is consistent with all other integrals.
From Example B in the DIP:
```
int f(bool b) { return 1; }
int f(int i) { return 2; }
enum E : int
{
a = 0,
b = 1,
c = 2,
}
```
Here, f(a) and f(b) call the bool overload, while f(c) calls the int
version. This works because D selects the overload with the tightest
conversion.
Why is that? Is it because "a" and "b" are enum members? I mean, "E" is
typed as an int. If I pass an integer literal directly to the function
it doesn't behave like that. Example:
import std.stdio;
void foo(int a)
{
writeln("int");
}
void foo(bool a)
{
writeln("bool");
}
void main()
{
foo(0);
foo(1);
foo(2);
}
The above example prints "int" three times. The bool overload is not
called. Seems like the enum is treated specially.
--
/Jacob Carlborg
Re: xlsxd: A Excel xlsx writer
On Saturday, 10 November 2018 at 10:55:04 UTC, Dave wrote:
Could you please elaborate a bit on your workflow for D with
Vim? E.g. what do you use for debugging, refactoring, ... ?
I had a lot of functions looking like this
void chart_axis_set_name(lxw_chart_axis* handle, const(char)*
name)
I had to transform into
void setName(string name) {
chart_axis_set_name(this.handle, toStringz(name));
}
For that I created a handful of (neo)vim macros that basically it
the transformations for me.
On my neovim setup. I use dutly. Dscanner generates ctags
recursively when I press F7. Which Ctrl-P uses for jump marks.
I use kdbg to debug, its just a somewhat pretty frontend to gdb.
Thats pretty much it.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote: I was hoping that this DIP was convincing enough, and its failure is certainly disappointing. Indeed.
Re: DMD backend now in D
On Sunday, 11 November 2018 at 23:40:16 UTC, Walter Bright wrote: As: https://github.com/dlang/dmd/pull/8946 removes the header files for the old C++ code! This makes me happy.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, November 12, 2018 2:45:14 AM MST Mike Parker via Digitalmars-d- announce wrote: > DIP 1015, "Deprecation and removal of implicit conversion from > integer and character literals to bool, has been rejected, > primarily on the grounds that it is factually incorrect in > treating bool as a type distinct from other integral types. *sigh* Well, I guess that's the core issue right there. A lot of us would strongly disagree with the idea that bool is an integral type and consider code that treats it as such as inviting bugs. We _want_ bool to be considered as being completely distinct from integer types. The fact that you can ever pass 0 or 1 to a function that accepts bool without a cast is a problem in and of itself. But it doesn't really surprise me that Walter doesn't agree on that point, since he's never agreed on that point, though I was hoping that this DIP was convincing enough, and its failure is certainly disappointing. - Jonathan M Davis
DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
DIP 1015, "Deprecation and removal of implicit conversion from
integer and character literals to bool, has been rejected,
primarily on the grounds that it is factually incorrect in
treating bool as a type distinct from other integral types.
The TL;DR is that the DIP is trying to change behavior that is
working as intended.
From Example A in the DIP:
bool b = 1;
This works because bool is a "small integral" with a range of
0..1. The current behavior is consistent with all other integrals.
From Example B in the DIP:
```
int f(bool b) { return 1; }
int f(int i) { return 2; }
enum E : int
{
a = 0,
b = 1,
c = 2,
}
```
Here, f(a) and f(b) call the bool overload, while f(c) calls the
int version. This works because D selects the overload with the
tightest conversion. This behavior is consistent across all
integral types. Replace bool with ubyte and f(a), f(b) would both
call the ubyte version. The same holds for the DIP's Example C.
Walter and Andrei left the door open to change the overload
behavior for *all* integral types, with the caveat that it's a
huge hurdle for such a DIP to be accepted. It would need a
compelling argument.
You can read a few more details in the summary I appended to the
DIP:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1015.md#formal-assessment
Thanks to Mike Franklin for sticking with the process to the end.
