On Monday, 23 July 2018 at 18:31:03 UTC, John Colvin wrote:
On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
On Mon, Jul 23, 2018 at 04:26:42PM +, Seb via
Digitalmars-d wrote:
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo(
On 25/07/2018 5:55 AM, Neia Neutuladh wrote:
Similarly, struct initializer syntax everywhere slightly reduces the
need for named arguments, albeit with some inconvenience:
It actually doesn't surprisingly.
As long as you support it for templates as well.
At which point it creates a nice consi
Am Sat, 21 Jul 2018 19:22:05 +
schrieb 12345swordy :
> On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote:
>
> > Frankly speaking, my feeling is that D is becoming a horrible
> > mess for the programmer...
>
> > /Paolo
> How!? Please Explain. You need to demonstrate evide
http://wg21.link/P0709
Interesting read. Looks like they want to bake something like
llvm::Expected into the language. I wonder if D shares all
these dynamic exceptions issues.
In any case it should become relevant if they really change the C
ABI as well.
On Tuesday, 24 July 2018 at 21:50:10 UTC, Jonathan M Davis wrote:
On Tuesday, July 24, 2018 20:25:33 12345swordy via
Digitalmars-d wrote:
I am asking this, because if true then the DIP that I am
currently working on has been render obsolete as I have taken
the old Object class into account when
On Tuesday, 24 July 2018 at 21:03:00 UTC, Patrick Schluter wrote:
On Tuesday, 24 July 2018 at 19:39:10 UTC, Ecstatic Coder wrote:
He gets different results with and without optimization
because without optimization the result of the calculation is
spilled to the i unsigned int and then reloaded
On Tuesday, July 24, 2018 20:25:33 12345swordy via Digitalmars-d wrote:
> I am asking this, because if true then the DIP that I am
> currently working on has been render obsolete as I have taken the
> old Object class into account when writing this.
It is not the plan to deprecate Object (nice as
On Tuesday, 24 July 2018 at 21:34:34 UTC, arturg wrote:
On Tuesday, 24 July 2018 at 21:05:05 UTC, Jean-Louis Leroy
wrote:
What is `PT` here:
https://github.com/dlang/phobos/blob/master/std/traits.d#L1224
Where does it come from?
https://dlang.org/spec/expression.html#is_expression
look for
6
On Tuesday, 24 July 2018 at 21:05:05 UTC, Jean-Louis Leroy wrote:
What is `PT` here:
https://github.com/dlang/phobos/blob/master/std/traits.d#L1224
Where does it come from?
https://dlang.org/spec/expression.html#is_expression
look for
6. is ( Type Identifier == TypeSpecialization )
On Tuesday, 24 July 2018 at 21:09:36 UTC, Seb wrote:
On Tuesday, 24 July 2018 at 20:25:33 UTC, 12345swordy wrote:
I am asking this, because if true then the DIP that I am
currently working on has been render obsolete as I have taken
the old Object class into account when writing this.
-Alexan
On Tuesday, 24 July 2018 at 21:05:05 UTC, Jean-Louis Leroy wrote:
What is `PT` here:
https://github.com/dlang/phobos/blob/master/std/traits.d#L1224
Where does it come from?
`PT` is an identifier chosen by the programmer (see
https://dlang.org/spec/expression.html#is_expression;
specifically
On Tuesday, 24 July 2018 at 20:59:22 UTC, Patrick Schluter wrote:
On Tuesday, 24 July 2018 at 19:24:05 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 15:08:35 UTC, Patrick Schluter
wrote:
On Tuesday, 24 July 2018 at 14:41:17 UTC, Ecstatic Coder
wrote:
On Tuesday, 24 July 2018 at 14:08:
What is `PT` here:
https://github.com/dlang/phobos/blob/master/std/traits.d#L1224
Where does it come from?
On Tuesday, 24 July 2018 at 20:25:33 UTC, 12345swordy wrote:
I am asking this, because if true then the DIP that I am
currently working on has been render obsolete as I have taken
the old Object class into account when writing this.
-Alexander
It's called ProtoObject and "deprecated".
And no
On Tuesday, 24 July 2018 at 19:39:10 UTC, Ecstatic Coder wrote:
He gets different results with and without optimization
because without optimization the result of the calculation is
spilled to the i unsigned int and then reloaded for the print
call. This save and reload truncated the value to i
On Tuesday, 24 July 2018 at 19:24:05 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 15:08:35 UTC, Patrick Schluter
wrote:
On Tuesday, 24 July 2018 at 14:41:17 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 14:08:26 UTC, Daniel Kozak wrote:
I am not C++ expert so this seems wier
I am asking this, because if true then the DIP that I am
currently working on has been render obsolete as I have taken the
old Object class into account when writing this.
-Alexander
He gets different results with and without optimization because
without optimization the result of the calculation is spilled
to the i unsigned int and then reloaded for the print call.
This save and reload truncated the value to its real value. In
the optimized version, the compiler removed th
On Tuesday, 24 July 2018 at 15:08:35 UTC, Patrick Schluter wrote:
On Tuesday, 24 July 2018 at 14:41:17 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 14:08:26 UTC, Daniel Kozak wrote:
I am not C++ expert so this seems wierd to me:
#include
#include
using namespace std;
int main(int
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
I personally prefer option 2, but this might be in conflict to
named arguments which we hopefully see in the near future too.
Hence, I'm leaning forward to proposing Option 1 as the
recommended Option for the DIP (that's also what the PoC DMD
On Tuesday, 24 July 2018 at 17:14:53 UTC, Chris M. wrote:
On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
[...]
No. For many C++ users, tracing GC is absolutely not an
option. And, if it were, D's GC is not a shining exampl
On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
[...]
No. For many C++ users, tracing GC is absolutely not an option.
And, if it were, D's GC is not a shining example of a good GC.
It's not even precise, and I would bet tha
On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder
wrote:
So, at the moment, I don't see how you can EASILY con
On Tue, Jul 24, 2018 at 01:13:16PM +, Dukc via Digitalmars-d wrote:
> On Tuesday, 24 July 2018 at 12:37:21 UTC, Cym13 wrote:
> > That argument sounds quite dangerous to me, especially since my
> > experience is on the contrary that constructor arguments are often
> > named the same as the attri
On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
So, at the moment, I don't see how you can EASILY convince
people to use BetterC for C/C++ use cases, like
On Monday, 23 July 2018 at 17:26:16 UTC, Steven Schveighoffer
wrote:
On 7/22/18 8:13 AM, Anonymouse wrote:
Can this be made a compiler warning?
struct Foo
{
int i;
}
void main()
{
Foo foo;
with (foo)
{
i = 42;
int i;
i = 24;
}
}
I'm hesitan
On Tuesday, 24 July 2018 at 14:41:17 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 14:08:26 UTC, Daniel Kozak wrote:
I am not C++ expert so this seems wierd to me:
#include
#include
using namespace std;
int main(int argc, char **argv)
{
char c = 0xFF;
std::string sD
On Tuesday, 24 July 2018 at 14:08:26 UTC, Daniel Kozak wrote:
I am not C++ expert so this seems wierd to me:
(...)
int main(int argc, char **argv)
{
char c = 0xFF;
std::string sData = {c,c,c,c};
unsigned int i = (sData[0]&0xFF)*256
On Tuesday, 24 July 2018 at 14:08:26 UTC, Daniel Kozak wrote:
I am not C++ expert so this seems wierd to me:
#include
#include
using namespace std;
int main(int argc, char **argv)
{
char c = 0xFF;
std::string sData = {c,c,c,c};
unsigned int i = (sData[0]&0xFF)*256
On Tuesday, 24 July 2018 at 14:08:26 UTC, Daniel Kozak wrote:
I am not C++ expert so this seems wierd to me:
#include
#include
using namespace std;
int main(int argc, char **argv)
{
char c = 0xFF;
std::string sData = {c,c,c,c};
unsigned int i = (sData[0]&0xFF)*256
On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
So, at the moment, I don't see how you can EASILY convince
people to use BetterC for C/C++ use cases, like programming
games, microcontrollers, etc.
*Extremely powerful
I am not C++ expert so this seems wierd to me:
#include
#include
using namespace std;
int main(int argc, char **argv)
{
char c = 0xFF;
std::string sData = {c,c,c,c};
unsigned int i = (sData[0]&0xFF)*256
+ (sData[1]&0xFF))*256
On Tuesday, 24 July 2018 at 12:13:27 UTC, Atila Neves wrote:
On Tuesday, 24 July 2018 at 11:53:35 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 10:40:33 UTC, Dukc wrote:
On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
[...]
They already work, except for the concatenat
On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
So, at the moment, I don't see how you can EASILY convince
people to use BetterC for C/C++ use cases, like programming
games, microcontrollers, etc.
*Extremely powerful meta programming that blows c++ meta
programming out of the
On Tuesday, 24 July 2018 at 12:37:21 UTC, Cym13 wrote:
That argument sounds quite dangerous to me, especially since my
experience is on the contrary that constructor arguments are
often named the same as the attribute they refer to. And what
of mixed cases? I really wouldn't rely on anything li
On Tuesday, 24 July 2018 at 10:48:40 UTC, Dukc wrote:
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
What's your take on this?
Option 2 won't necessarily cause problems with named funcion
arguments: The names of the constructor arguments and members
are different anyway, at least usuall
On Tuesday, 24 July 2018 at 11:53:35 UTC, Ecstatic Coder wrote:
On Tuesday, 24 July 2018 at 10:40:33 UTC, Dukc wrote:
On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
[...]
They already work, except for the concatenation operator
because it obviously requires the GC. And conver
On Tuesday, 24 July 2018 at 10:40:33 UTC, Dukc wrote:
On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
And something that REALLY must be integrated into BetterC's
low-level standard library in some way IMHO...
They already work, except for the concatenation operator
because it o
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
What's your take on this?
Option 2 won't necessarily cause problems with named funcion
arguments: The names of the constructor arguments and members are
different anyway, at least usually, letting the compiler to infer
the intended call by
On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
And something that REALLY must be integrated into BetterC's
low-level standard library in some way IMHO...
They already work, except for the concatenation operator because
it obviously requires the GC. And converiting a pointer fro
On Tuesday, 24 July 2018 at 00:15:37 UTC, spikespaz wrote:
I needed a truncate function on the `std.stdio.File` object, so
I made this function. Does it look okay? Are there any
cross-platform improvements you can think of that should be
added?
import std.stdio: File;
void truncate(File fil
On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote:
On Monday, 23 July 2018 at 22:45:15 UTC, Walter Bright wrote:
I've predicted before that what will kill C is managers and
customers requiring memory safety because unsafeness costs
them millions. The "just hire better programmers" will never
On Monday, 23 July 2018 at 22:45:15 UTC, Walter Bright wrote:
On 7/23/2018 5:39 AM, Joakim wrote:
In my experience, people never learn, even from the blatantly
obvious, _particularly_ when they're invested in the outdated.
What inevitably happens is the new tech gets good enough to
put them ou
On 24/07/2018 7:23 PM, Daniel N wrote:
On Tuesday, 24 July 2018 at 03:59:53 UTC, rikki cattermole wrote:
On 24/07/2018 6:43 AM, kinke wrote:
On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote:
Can we just consider that named struct init syntax *is* a generated
named constructor?
If named a
On Tuesday, 24 July 2018 at 03:59:53 UTC, rikki cattermole wrote:
On 24/07/2018 6:43 AM, kinke wrote:
On Monday, 23 July 2018 at 17:32:23 UTC, aliak wrote:
Can we just consider that named struct init syntax *is* a
generated named constructor?
If named arguments choose a different syntax then
On Tuesday, 24 July 2018 at 01:31:13 UTC, JohnB wrote:
On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote:
Customers do not understand about programming. Your lucky
if most clients can even get a proper specification formulated
for what they want. If clients are that knowledgeable we do
On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote:
I am sorry to say but to succeed as a language beyond being a
small or hobby language it takes: Being established already or
having a big name to hype behind your "product". Anything
beyond that will have topic derail and frankly, its more
47 matches
Mail list logo
