Re: Overflows in Phobos
On Sunday, July 31, 2016 21:45:25 Cauterite via Digitalmars-d wrote: > On Saturday, 30 July 2016 at 00:55:11 UTC, Charles Hixson wrote: > > FWIW, in that case I always use > > assert (false, "..."); > > I try to never use integers for booleans. But this may well be > > a common usage. > > I suspect `assert(0)` is really `assert( constexpr>)`, so you should be fine. Both styles are used in > Phobos. assert(false) is definitely equivalent to assert(0) as is any other assertion where the compiler decides that the condition is known to be false at compile time. However, it's not like enum or static where the condition is forced to be evaluated at compile time. So, I don't know where it draws the line between determining the condition at compile time and letting that expression be evaluated at runtime. I wouldn't advise relying on it being compile time for stuff beyond 0 or false even though there are other cases where the compiler will decide that it knows that it's false at compile time. - Jonathan M Davis
Re: Overflows in Phobos
On Saturday, 30 July 2016 at 00:55:11 UTC, Charles Hixson wrote: FWIW, in that case I always use assert (false, "..."); I try to never use integers for booleans. But this may well be a common usage. I suspect `assert(0)` is really `assert(constexpr>)`, so you should be fine. Both styles are used in Phobos.
Re: alias parameters and basic types
On Sunday, 31 July 2016 at 11:50:35 UTC, Steven Schveighoffer wrote: On 7/30/16 5:26 PM, deadalnix wrote: I take that, as you weren't there at the 2016 event, it was reiterated in 2016. Timon was at dconf 2016. I don't recall it being discussed either, but maybe in a small discussion? I meant he was not there in 2015, sorry for the confusion.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 21 July 2016 at 16:39:18 UTC, Andrew Godfrey wrote: You seem to be assuming that everyone already agrees on which set of changes should be made to the language. (Otherwise, how could you expect anyone to "officially back" a side project?) But agreeing on which changes to make and, especially, which to NOT make, is the hard part. And it's why you'd need a lot of planning & discussion up front (if any of us non-founders wanted to participate). And many people don't understand this, which IMO is behind a lot of hard feelings in the forums. The basic idea would be not to radically change the language, but come down to a clean core and build the existing useful concepts on top of that core. A year ago or so it was claimed that the compiler core would would be refactored and before that it was asked in the forum if current users would prefer non-breaking changes or a clean up. My impression was that the majority was willing to take some breaking changes in order to get a more streamlined experience. Anyway, it is summertime, maybe we can discuss this later in the autumn ;-). (I don't have time to follow the forums.)
Re: [OT] Music to Program Compilers To
On Friday, 29 July 2016 at 22:44:04 UTC, Walter Bright wrote: http://70sdisconights.com/ Yes, I listen to it while I work. For a somewhat more...traditional genre: http://musopen.org/radio
Re: Vision for the D language - stabilizing complexity?
On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote: You can lower D to Assembler and analyze that. Assembler is simple, isn't it? You can, and that is what C++ is mostly limited to, but you then you most likely get false positives and cannot use the analysis as part of the type-system. If you are going to use e.g. pointer analysis as part of the type system, then it has to happen at a higher level.
Re: [DIP] In-place struct initialization
On Sunday, 31 July 2016 at 14:38:33 UTC, Lodovico Giaretta wrote:
On Sunday, 31 July 2016 at 13:39:58 UTC, Enamex wrote:
I suggest extending the existing `S s = {field: value}` syntax
to allow specifying the type itself next to the field list and
make it usable generally everywhere.
So, instead:
takeThing(Thing{ field: val, num: 43 });
It shouldn't clash with anything else, I think.
I support this idea of extending curly-brace initializers. It
would be very useful and less ambiguous than parenthesized
initializers.
[A thread about this]
http://forum.dlang.org/post/ni0u47$2100$1...@digitalmars.com
[An issue about this]
https://issues.dlang.org/show_bug.cgi?id=15692
It's strange that D wouldn't support something like that as even
C (C99) can do it with compound literals (struct s){ .z = "Pi",
.x = 3, .y = 3.1415 }. It's absolutely possible to pass it to a
function taking a struct s. You can even take its address with &
if the fonction take a pointer to a struct. I use it all the time
on my work project.
Re: [DIP] In-place struct initialization
On Sunday, 31 July 2016 at 13:39:58 UTC, Enamex wrote:
I suggest extending the existing `S s = {field: value}` syntax
to allow specifying the type itself next to the field list and
make it usable generally everywhere.
So, instead:
takeThing(Thing{ field: val, num: 43 });
It shouldn't clash with anything else, I think.
I support this idea of extending curly-brace initializers. It
would be very useful and less ambiguous than parenthesized
initializers.
[A thread about this]
http://forum.dlang.org/post/ni0u47$2100$1...@digitalmars.com
[An issue about this]
https://issues.dlang.org/show_bug.cgi?id=15692
Re: [DIP] In-place struct initialization
On Sunday, 31 July 2016 at 07:10:46 UTC, cym13 wrote:
The proposed change is litteraly just equivalent to the already
existing struct initialization, just made usable:
struct S {
int a;
int b;
}
auto s = S(b:42);
// equivalent to
S s = { b:42 };
Having the possibility to initialize structs without tying them
to a variable
proves useful when combined with functions that take this
struct but those
functions aren't directly impacted by the change.
I suggest extending the existing `S s = {field: value}` syntax to
allow specifying the type itself next to the field list and make
it usable generally everywhere.
So, instead:
takeThing(Thing{ field: val, num: 43 });
It shouldn't clash with anything else, I think.
Re: alias parameters and basic types
On 7/30/16 5:26 PM, deadalnix wrote: On Saturday, 30 July 2016 at 21:21:30 UTC, Timon Gehr wrote: On 30.07.2016 22:58, Jonathan M Davis via Digitalmars-d wrote: The one that needs to be convinced is Walter. IIRC he said at DConf that it should be fixed. We did a tour of DConf 2015 with David Nadlinger and everybody was super confused by this behavior. Pretty much everybody but Walter, David and myself could tell you how this behaves. Even Andrei got it wrong. Walter got it wrong too, I saw when David asked him. That's when he said it should be fixed. The question was, if I alias Int = int, then Int is a symbol. If I pass it as an alias parameter, should it work? I take that, as you weren't there at the 2016 event, it was reiterated in 2016. Timon was at dconf 2016. I don't recall it being discussed either, but maybe in a small discussion? I think we should fix this. The fact that you can alias int directly, but it can't be accepted as an alias parameter makes no sense. It's completely doable, and the philosophical argument is destroyed by the example. -Steve
Re: [OT] Music to Program Compilers To
On Sunday, 31 July 2016 at 08:25:12 UTC, ketmar wrote: On Sunday, 31 July 2016 at 07:52:43 UTC, Russel Winder wrote: The point here is to get up out of the chair for at least 2 mins every 40 mins to 60 mins. while this may be good for physical state, at least with me it throws me away from "zone", and I need from 10 to 30 minutes to get back to work. not even "to full-speed work", but "just to work". and second or third such distraction puts me to "meh, I'm done today". I'll have to agree. If I get interrupted 3 or more times in short succession (be it the cats insisting I put more food down, scratching at the door, phone calls, or someone asking me to get them a glass of water because they don't feel like getting up) I'm ready to call it quits for the day. I don't really think I can stand to sit in one spot for as long as 40 minutes anyways. Maybe my chairs are too flat, but I end up shifting quite often or going to get a drink of water when I feel like it, rather than a mandatory every 60 minutes. I'll then wander for several minutes before finally going back to my chair. Being forced to reset or press play on a CD player is just an annoyance, I'm more likely to put it on auto-repeat, as I can listen to the same album several times or the same song for a few hours straight before I need to change it. There's always the possibility you won't notice the music stopped either and go for another half hour or an hour before you realize it, especially when you're in the groove.
Re: [OT] Music to Program Compilers To
On Sunday, 31 July 2016 at 07:52:43 UTC, Russel Winder wrote: The point here is to get up out of the chair for at least 2 mins every 40 mins to 60 mins. while this may be good for physical state, at least with me it throws me away from "zone", and i need from 10 to 30 minutes to get back to work. not even "to full-speed work", but "just to work". and second or third such distraction puts me to "meh, i'm done today".
Re: [DIP] In-place struct initialization
On Sunday, 31 July 2016 at 07:10:46 UTC, cym13 wrote: I don't understand this comment. That's because you haven't tried to specify the grammar. I suggest you try.
Re: [OT] Music to Program Compilers To
On Sat, 2016-07-30 at 19:13 +, Antonio Corbi via Digitalmars-d wrote: > On Friday, 29 July 2016 at 22:44:04 UTC, Walter Bright wrote: > > > > http://70sdisconights.com/ > > > > Yes, I listen to it while I work. > > I usually listen to several channels from somafm.com (depending > on my mood) but for programming tasks I tend to listen to "sf > 10-33" (Ambient music mixed with the sounds of San Francisco > public safety radio traffic) and latelly to "Mission Control" > (Celebrating NASA and Space Explorers everywhere.", I find them > very soothing. Programmers should never listen to music generated by their computer, nor CDs played in their computer. Programmers should always use CDs in a CD player out of reach of the position for programming. Also the CD player remote should not be in reach. Every time the CD stops you get up change to a new CD and then get on with programming. If you are all neophyte and new fangled (and lower quality even than CDs) restrict your MP3 or Ogg Vorbis player (not the computer for programming) to one album at a time, and put the device out of reach. Never put a radio on. The point here is to get up out of the chair for at least 2 mins every 40 mins to 60 mins. For the really keen to stay fit and alive you might want to do a few stretching exercises whilst changing the music. Especially fingers. And neck. I recommend "The eight pieces of silk brocade" qigong. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [DIP] In-place struct initialization
On Sunday, 31 July 2016 at 04:55:31 UTC, deadalnix wrote:
On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:
The most interesting is to use structs to mimic keyword
arguments for
functions. By encapsulating possible arguments in a struct it
is possible to
use in-place initialization to provide a clean interface very
similar to
keyword arguments such as seen in python or ruby.
That doesn't help. In fact, it makes things worse as now
constructor calls and function call do not have the same
syntax. You've just created an holly mess in the parser.
If something we should strive to get constructor call more like
regular function call rather than less (for instance by
behaving the same way when it comes to IFTI).
It is also unclear how overload resolution is supposed to work.
If I may suggest one thing it is to not start with the intended
result for the DIP, but start from the intended change int he
language, then, and only then, examine what comes out of it.
I don't understand this comment. This isn't about construction,
it's about initialization, the call can occur only at one precise
time and no there is no overload concern as there is no function
call. The proposed change is litteraly just equivalent to the
already existing struct initialization, just made usable:
struct S {
int a;
int b;
}
auto s = S(b:42);
// equivalent to
S s = { b:42 };
Having the possibility to initialize structs without tying them
to a variable
proves useful when combined with functions that take this struct
but those
functions aren't directly impacted by the change.
