Re: Bug? opIn with associative array keyed on static arrays
On Sunday, 22 July 2018 at 19:42:45 UTC, Peter Alexander wrote:
void main() {
int[int[1]] aa;
aa[[2]] = 1;
assert([2] in aa);
}
---
This assertion fails in 2081.1. Is this a bug?
https://dpaste.dzfl.pl/d4c0d4607482
https://issues.dlang.org/show_bug.cgi?id=19112
Re: throwing lots of resources at a GC
On Friday, 20 July 2018 at 00:46:37 UTC, John Belmonte wrote: Interesting (and way too detailed for me) tale of GC adventures in golang: https://blog.golang.org/ismmkeynote Seeing the pretty incredible reductions in additional latency was great. I would love to see some in-depth analysis of D's garbage collector.
Re: C's Biggest Mistake on Hacker News
On Sunday, 22 July 2018 at 20:10:27 UTC, Walter Bright wrote: On 7/21/2018 11:53 PM, Walter Bright wrote: My article C's Biggest Mistake on front page of https://news.ycombinator.com ! Direct link: https://news.ycombinator.com/item?id=17585357 The responses are not encouraging, but I suppose they're useful for sociologists studying fallacious thinking.
Re: with and shadowing variables
On Sunday, 22 July 2018 at 12:13:43 UTC, 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 hesitant to file a bug because it'll just be immediately
closed with a link to
https://dlang.org/spec/statement.html#WithStatement. I
understand that's how it works, but it's weird and weak to
human mistakes.
Do you have an actual case where it was a problem, as opposed to
a contrived example with semantically empty identifiers? I
recently saw another comment objecting to `with` altogether as
being obfuscating because you can't tell which symbols are
qualified by the symbol in the with clause, when the obfuscation
was clearly due to the meaningless names in the poster's example.
Re: with and shadowing variables
On Sunday, 22 July 2018 at 14:05:45 UTC, Jonathan M Davis wrote:
On Sunday, July 22, 2018 12:13:43 Anonymouse via Digitalmars-d
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 hesitant to file a bug because it'll just be immediately
closed with a link to
https://dlang.org/spec/statement.html#WithStatement. I
understand that's how it works, but it's weird and weak to
human mistakes.
Given the shadowing protections listed in #5, it could
certainly be argued that it would be in the spirit of the
restrictions that with already has, and I think that there's a
pretty clear argument to be made that allowing it is too
error-prone, but maybe someone will have a reason why it
doesn't make sense to disallow it. I don't know. Regardless, I
would suggest that you open an enhancement request. I would
guess that it's straightforward enough that a DIP isn't
reauired so long as Walter approves of it, but I don't know.
Either way, if it's in bugzilla, then it stands a much better
chance of happening than if the only record of it is here.
- Jonathan M Davis
#5 says that a symbol defined in an outer scope and used within
the with block must not also be a member of Foo, to prevent a
silent change in the meaning of the code if that symbol gets
added to Foo -- #5 will result in an error message if that
happens. Nothing like that applies here ... clearly the two `i's
are different, since you can't use a symbol before it's defined
(except at top level). You might want to argue that it should be
disallowed (I wouldn't), but I don't think you can use "the
spirit of #5" to do so.
Re: with and shadowing variables
On Monday, 23 July 2018 at 12:01:19 UTC, Jim Balter wrote:
Do you have an actual case where it was a problem, as opposed
to a contrived example with semantically empty identifiers? I
recently saw another comment objecting to `with` altogether as
being obfuscating because you can't tell which symbols are
qualified by the symbol in the with clause, when the
obfuscation was clearly due to the meaningless names in the
poster's example.
Copy/pasted but changed some bits for clarity.
struct IRCServer
{
// ...
string prefixchars;
string prefixes; // <--
}
struct IRCBot
{
// ...
IRCServer server;
}
struct IRCParser
{
// ...
IRCBot bot;
}
IRCParser parser;
// string content == "EXCEPTS INVEX PREFIX=(Yqaohv)!~&@%+";
foreach (entry; content.splitter(" "))
{
// Roughly rewritten splitting
auto split = entry.findSplit("=");
string key = split[0];
string value = split[2];
with (parser.bot.server)
switch (key)
{
case "PREFIX":
// PREFIX=(Yqaohv)!~&@%+
import std.format : formattedRead;
string modes;
string prefixes; // <--
value.formattedRead("(%s)%s", modes, prefixes);
foreach (immutable i; 0..modes.length)
{
prefixchars[prefixes[i]] = modes[i]; //
parser.bot.server.prefixchars
prefixes ~= modes[i]; // <-- accidental local
prefixes instead of parser.bot.server.prefixes
}
break;
// ...
default:
break;
}
https://github.com/zorael/kameloso/blob/93002da193eac2dfbfeb6c8756feb2d74a345530/source/kameloso/irc.d#L1887
Re: with and shadowing variables
On Sunday, 22 July 2018 at 12:13:43 UTC, Anonymouse wrote: I'm hesitant to file a bug because it'll just be immediately closed with a link to https://dlang.org/spec/statement.html#WithStatement. I understand that's how it works, but it's weird and weak to human mistakes. IMO the only reasonable thing to do with `with` is not to use it, generally speaking. Maybe in D the only exception would be with an named enum ( the final switch pattern). But otherwise the WithStatement, D or not, is known for being a big nono.
Re: C's Biggest Mistake on Hacker News
On Monday, 23 July 2018 at 11:51:54 UTC, Jim Balter wrote: On Sunday, 22 July 2018 at 20:10:27 UTC, Walter Bright wrote: On 7/21/2018 11:53 PM, Walter Bright wrote: My article C's Biggest Mistake on front page of https://news.ycombinator.com ! Direct link: https://news.ycombinator.com/item?id=17585357 The responses are not encouraging, but I suppose they're useful for sociologists studying fallacious thinking. 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 out of business, then they finally pick it up or retire. Until most system software is written in D/Go/Rust/Swift/Zig/etc., they will keep mouthing platitudes about how C is here to stay.
Re: C's Biggest Mistake on Hacker News
On Monday, 23 July 2018 at 11:51:54 UTC, Jim Balter wrote: On Sunday, 22 July 2018 at 20:10:27 UTC, Walter Bright wrote: On 7/21/2018 11:53 PM, Walter Bright wrote: My article C's Biggest Mistake on front page of https://news.ycombinator.com ! Direct link: https://news.ycombinator.com/item?id=17585357 The responses are not encouraging, but I suppose they're useful for sociologists studying fallacious thinking. I agree. As I've already said in the past here on this forum, D's way of managing string/array/slices in the same manner is one of its biggest advances over C/C++, both in safety and expressivity. Very simple stuff indeed, but still lightyears ahead of C++, Java, C#, etc. And something that REALLY must be integrated into BetterC's low-level standard library in some way IMHO...
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On Tuesday, 3 July 2018 at 03:27:06 UTC, Ali wrote:
Well, D is not exactly known for contract oriented programming
or DbC (Design by Contract)
we have to thank Bertrand Meyer and his language Eiffel, for
that
Thanks for pointing this out !
His book "Object-Oriented Software Construction" is an absolute
MUST-READ for any decent programmer.
Contracts, large-scale object-oriented architecture, how to
assign responsabilities to the right class, etc.
Even somthing seemingly insignificant as using uppercase
typenames is a complete life changer, as this way you can
immediately see the role of a single-word identifier just by its
case.
That's after reading his book almost three decades ago that I've
decided to use the following conventions for my personal code :
- PLAYER : type
- Player : member variable
- player : local variable
Still don't understand why people are still adding silly prefixes
or suffixes ("m_", "_", "this->", etc etc) to differentiate local
variables from member variables etc :
- Player : type
- player_, _player, m_player, this->player, etc : member variable
- player : local variable
While using the identifier case gets the job done in a simpler
and more readable way...
IMO reading this book should be mandatory for any second-year
student who is learning professional software development...
Struct Initialization syntax
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
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 PR
implements). What's your take on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote: Hence, I'm leaning forward to proposing Option 1 as the recommended Option for the DIP (that's also what the PoC DMD PR implements). What's your take on this? Although a bit more verbose that seems like a good choice. If you could save the “initialization list” in an enum that choice also seems to generalize better. Not conflicting with named arguments is important for me, as named arguments would be very nice to have for hardware description kind of stuff.
Re: Struct Initialization syntax
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()
> {
> bar(S({c: 10})); // Option 1
> bar(S(c: 10)); // Option 2
> bar(S{c: 10}); // Option 3
> }
> ---
>
> So the struct-initialization DIP has been stalled for too long and I
> think it's time we finally get this story done.
+1.
> I personally prefer option 2, but this might be in conflict to named
> arguments which we hopefully see in the near future too.
Yeah.
> Hence, I'm leaning forward to proposing Option 1 as the recommended
> Option for the DIP (that's also what the PoC DMD PR implements).
> What's your take on this?
[...]
I don't like option 1 because it resembles anonymous function syntax and
AA initialization syntax, but is actually neither.
I'm on the fence about option 2 and option 3.
I actually prefer option 3 as being overtly special initialization
syntax that doesn't try to masquerade as something else.
But OTOH, option 2 has a lot going for it, given that today, S(x, y, z)
is the syntax for initializing struct fields in order, so one would
expect that S(p: x, q: y, r: z) ought to be a natural extension of the
syntax for specifying fields out-of-order (or with some fields omitted).
It's true that there's potential conflict with named arguments, but IMO
it's a mighty bad idea to name ctor parameters in a way that conflicts
with the struct fields. Either your struct has a member named x, your
ctor uses parameter names that are different from x (thus avoiding the
confusion), or if your ctor also takes a parameter named x, in which
case one would expect that it would initialize the member x, as opposed
to a different member y. To have a ctor take a parameter named x but
using it to initialize member y instead of member x, seems to be such a
horrible idea that it should not be a big deal for struct initialization
syntax to "conflict" with it.
T
--
If you want to solve a problem, you need to address its root cause, not just
its symptoms. Otherwise it's like treating cancer with Tylenol...
static foreach and function generation
Consider:
module genfun;
import std.stdio, std.format, std.traits;
void foo(int a) { writeln("foo(%s)".format(a)); }
void foo(int a, int b) { writeln("foo(%s, %s)".format(a, b)); }
static foreach (fun; __traits(allMembers, genfun)) {
static if (fun == "foo") {
static if (is(typeof(__traits(getOverloads, genfun, fun
{
static foreach (ovl; __traits(getOverloads, genfun, fun))
{
void foobar(Parameters!ovl args) { // HERE
write("calling ");
foo(args); // HERE
}
}
}
}
}
void main()
{
foobar(1); // calling foo(1)
foobar(1, 2); // calling foo(1, 2)
}
Now I would like to change `foo` and `foobar` to calculated
symbols where marked. I would also like to use as little string
mixin as possible. I tried:
static foreach (fun; __traits(allMembers, genfun)) {
static if (fun == "foo") {
static if (is(typeof(__traits(getOverloads, genfun, fun
{
static foreach (ovl; __traits(getOverloads, genfun, fun))
{
void mixin(fun + "bar")(Parameters!ovl args) { // 1
write("calling ");
mixin(fun)(args); // 2
}
}
}
}
}
This gets me halfway there: #2 works but #1 does not.
This works:
static foreach (fun; __traits(allMembers, genfun)) {
static if (fun == "foo") {
static if (is(typeof(__traits(getOverloads, genfun, fun
{
static foreach (ovl; __traits(getOverloads, genfun, fun))
{
void internal(Parameters!ovl args) {
mixin(fun)(args);
}
mixin("alias %sbar = internal;".format(fun));
}
}
}
}
Does anyone see a potential problems with this? Or a better
solution? I would like to avoid the alias.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
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 PR
implements). What's your take on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
I'm in favour of 3.
Option 2 looks nice but I'm against it because of possible named
arguments. Even though they're not part of the language yet and
may never be we already have too many clunky things not to avoid
a conflict when we can.
Option 1 is clean but a bit strange, I don't like the idea of
doubling the enclosing symbols, in that situation you'd expect
S() and {} to have separate effects, not to combine into a
special effect. It also looks like a constructor while it's not,
which isn't a nice conflation to make. I wouldn't be very
dismayed by it though.
Still, that's why I prefer option 3 which is very similar to
classical struct initialization and has clearly only one effect.
PS: Now that I think about it, would something like S{c:3}("a")
be allowed to say “Call the constructor with the string "a" as
argument on the struct of type S initialized with c=3”? I may
have missed it but I don't think that's addressed by the DIP.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:10:08 UTC, Cym13 wrote:
PS: Now that I think about it, would something like S{c:3}("a")
be allowed to say “Call the constructor with the string "a" as
argument on the struct of type S initialized with c=3”? I may
have missed it but I don't think that's addressed by the DIP.
I took that last point to GH, no need to discuss it here.
Re: with and shadowing variables
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 hesitant to file a bug because it'll just be immediately closed with
a link to https://dlang.org/spec/statement.html#WithStatement. I
understand that's how it works, but it's weird and weak to human mistakes.
I'm with Jonathan, it should be an error. It shouldn't matter what scope
you declared `i` in, just when you use it, the ambiguity should trigger.
The fix is super-simple, name it something else!
Note that this won't fix other ambiguities. For example, if Foo has an
opDispatch that matches "i", or `i` is a UFCS function (actually, I
don't know if UFCS works using `with`).
-Steve
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
It's true that there's potential conflict with named arguments,
but IMO it's a mighty bad idea to name ctor parameters in a way
that conflicts with the struct fields.
After using Swift for a while, I've found this to be the exact
opposite. It is on the contrary very common to name parameters as
you would your members because they are very commonly the most
intuitive names.
struct Point {
int x, int y;
this(x: int, y: int) {}
}
auto p = Point(x: 3, y: 4); // what else would you name them?
Can we just consider that named struct init syntax *is* a
generated named constructor?
If named arguments choose a different syntax then you have no
conflict. If they go with the same (i.e. option 2) then you have
seamless consistency.
Cheers,
- Ali
Re: Struct Initialization syntax
On Mon, Jul 23, 2018 at 05:32:23PM +, aliak via Digitalmars-d wrote:
> On Monday, 23 July 2018 at 16:57:20 UTC, H. S. Teoh wrote:
>
> > It's true that there's potential conflict with named arguments, but
> > IMO it's a mighty bad idea to name ctor parameters in a way that
> > conflicts with the struct fields.
>
> After using Swift for a while, I've found this to be the exact
> opposite. It is on the contrary very common to name parameters as you
> would your members because they are very commonly the most intuitive
> names.
[...]
I worded myself poorly. What I meant was that if a ctor parameter has
the same name as a field, then it's obviously meant to initialize that
field, so there isn't really a conflict, you're just passing the
argument to the ctor instead of setting it directly to the struct. It
would be a horrendously bad idea to have a ctor parameter that has the
same name as a field, but is used to initialize a different field.
OTOH, if you have a ctor, then one would assume that you're
intentionally overriding direct initialization of fields, so you
wouldn't want people to be using named initialization of fields anyway,
they should be using the ctor instead. So any conflicts in this area
wouldn't really be relevant.
> struct Point {
> int x, int y;
> this(x: int, y: int) {}
> }
>
> auto p = Point(x: 3, y: 4); // what else would you name them?
>
> Can we just consider that named struct init syntax *is* a generated
> named constructor?
>
> If named arguments choose a different syntax then you have no
> conflict. If they go with the same (i.e. option 2) then you have
> seamless consistency.
[...]
Yes, this is what I was trying to get at. Thanks!
T
--
Don't modify spaghetti code unless you can eat the consequences.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:46:12 UTC, H. S. Teoh wrote: I worded myself poorly. What I meant was that if a ctor parameter has the same name as a field, then it's obviously meant to initialize that field, so there isn't really a conflict, you're just passing the argument to the ctor instead of setting it directly to the struct. It would be a horrendously bad idea to have a ctor parameter that has the same name as a field, but is used to initialize a different field. [...] If named arguments choose a different syntax then you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. [...] Yes, this is what I was trying to get at. Thanks! T Hehe oops, indeed you were :p Seems I did not parse properly. Apologies! Cheers, - Ali
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:46:12 UTC, H. S. Teoh wrote: Yes, this is what I was trying to get at. Thanks! If such integration was possible then that sounds like it would be a good solution.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
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 PR
implements). What's your take on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
I also prefer option 3. From a readability point of view it is
the most pleasant one (my personal opinion). I also like it due
to the already existing struct initialization syntax I am using a
lot.
Kind regards
Andre
Re: Struct Initialization syntax
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()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
+1.
I personally prefer option 2, but this might be in conflict to
named arguments which we hopefully see in the near future too.
Yeah.
Hence, I'm leaning forward to proposing Option 1 as the
recommended Option for the DIP (that's also what the PoC DMD
PR implements). What's your take on this?
[...]
I don't like option 1 because it resembles anonymous function
syntax and AA initialization syntax, but is actually neither.
Seeing as we already have
S s = { c : 10 };
I'd say it would be fairer to say it resembles anonymous function
syntax and AA initialisation syntax, but mostly it resembles the
existing struct initialisation syntax.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 18:02:04 UTC, Andre Pany wrote: I also prefer option 3. From a readability point of view it is the most pleasant one (my personal opinion). I also like it due to the already existing struct initialization syntax I am using a lot. +1. JohnB.
Re: Struct Initialization syntax
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 you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. +1. And hoping for the latter, seamless consistency.
Re: Struct Initialization syntax
On 2018-07-23 18:26, Seb wrote:
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long and I
think it's time we finally get this story done.
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 PR implements). What's your take on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
Talking about future potential features, Option 1 could be in conflict
with a tuple with named elements. Option 2 could be in conflict with
named parameters, true, but named parameters could also have a different
syntax, i.e. foo(a = 3, b = 4), this is what Scala is using.
--
/Jacob Carlborg
Re: static foreach and function generation
On 23.07.2018 19:05, Jean-Louis Leroy wrote:
This works:
static foreach (fun; __traits(allMembers, genfun)) {
static if (fun == "foo") {
static if (is(typeof(__traits(getOverloads, genfun, fun {
static foreach (ovl; __traits(getOverloads, genfun, fun)) {
void internal(Parameters!ovl args) {
mixin(fun)(args);
}
mixin("alias %sbar = internal;".format(fun));
}
}
}
}
Does anyone see a potential problems with this?
It generates additional symbols.
Or a better solution? I
would like to avoid the alias.
You can mix in the entire declaration.
mixin(`void `~fun~`bar(Parameters!ovl args) { mixin(fun)(args); }`);
It would of course be useful if the locations where string mixins can
occur were less restricted, such that things like
void mixin(fun~`bar`)(Parameters!ovl args){ ... }
would work too, but this will require a DIP.
Re: C's Biggest Mistake on Hacker News
On 7/23/2018 4:51 AM, Jim Balter wrote: The responses are not encouraging, but I suppose they're useful for sociologists studying fallacious thinking. A big motivation for starting D was not having to convince the C/C++ community of such things. I'd rather write code than argue.
Re: C's Biggest Mistake on Hacker News
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 out of business, then they finally pick it up or retire. Until most system software is written in D/Go/Rust/Swift/Zig/etc., they will keep mouthing platitudes about how C is here to stay. 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 work.
Truncate is missing from std.stdio.File, will this do the trick?
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 file, long offset) {
version (Windows) {
import core.sys.windows.windows: SetEndOfFile;
file.seek(offset);
SetEndOfFile(file.windowsHandle());
}
version (Posix) {
import core.sys.posix.unistd: ftruncate;
ftruncate(file.fileno(), offset);
}
}
Re: C's Biggest Mistake on Hacker News
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 work. I have yet to see a company Walter where higher ups will take correct actions to resolve issues. 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 not need to constantly deal with issues where clients had things in their heads different then what they told / envisioned. And most manager are not going to rock the boat and stick their necks out. Not when they can simply blame issues on programmer incompetence or "it has always been like that with programming languages". I have yet to see managers really taking responsibility beyond guiding the projects so they do not get fired and hope to rack in bonuses. Issues can always be blamed on the tools or programmers. Sorry but that response is so naive Walter that it surprises me. Its like wanting a unicorn. And frankly, good luck convincing any company to convert millions of C code into D code. Not when manager hear about some new language or framework or whatever that is the chizz. They rather keep running the old code and move to something new. D is not something new, its not the chizz, its the same issue that D has struggle with for years. Its the same reason why that topic derailed so fast. You want to see something fun. Mention PHP on HackerNews/Reddit and you see the exact same trolling. People rather push their new favorite language, be it Go, Rust, ... then pick D. Response at my work when i made some stuff in D... "Why did you not use Go". Because the managers knew Go from the hype. They know Google is behind it. And some of our colleagues in sister companies already used Go. And that is all it takes. 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 negative then positive. And D has too much old baggage. Its the same reason why PHP despite being a good language ( for what it is ), still keeps getting the exact same crude on forums. If i am honest, DasBetterC is a for me unreliable D product because using specific D library function can be GC. Or DasBetterC needs to be sold as C only, ever, forget about everything else that is D ( library, packages, ... ). Until everything is 100% GC free, your going to run into this. And even when its 100% GC free, people have long memories. Its always a struggle swimming up a river.
Re: C's Biggest Mistake on Hacker News
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 not need to constantly deal with issues where clients had things in their heads different then what they told / envisioned. I think that what Walter meant was when the customer have this problem where their data is leaking (and perhaps losing money) they will ask why, and an alternative to avoid this in the future will rely on a language that tend to follow the safety aspect. John B.
Re: Struct Initialization syntax
On 24/07/2018 7:11 AM, Jacob Carlborg wrote:
On 2018-07-23 18:26, Seb wrote:
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long and I
think it's time we finally get this story done.
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 PR implements). What's your take
on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
Talking about future potential features, Option 1 could be in conflict
with a tuple with named elements. Option 2 could be in conflict with
named parameters, true, but named parameters could also have a different
syntax, i.e. foo(a = 3, b = 4), this is what Scala is using.
We ugh can't use that syntax because of ambiguity to AssignExpression.
Re: Struct Initialization syntax
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 you have no conflict. If they go with the same (i.e. option 2) then you have seamless consistency. +1. And hoping for the latter, seamless consistency. Based upon my DIP that is in the queue for named arguments, it would be trivial for this DIP to make it so a named parameter constructor can override the default behavior and I think that this is the best way forward.
