Re: D, Parasail, Pascal, and Rust vs The Steelman
On Wednesday, 21 March 2018 at 16:08:07 UTC, Martin Tschierschke wrote: On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote: An article comparing the above languages as per the DoD language requirements [0]. http://jedbarber.id.au/steelman.html [0] - https://en.wikipedia.org/wiki/Steelman_language_requirements Interesting! Do you understand this: 7H. Formal Array Parameters. The number of dimensions for formal array parameters must be specified in programs and shall be determinable during translation. Determination of the subscript range for formal array parameters may be delayed until invocation and may vary from call to call. Subscript ranges shall be accessible within function and procedure bodies without being passed as explicit parameters. Subscript ranges are not accessible in D or Rust. I do not understand the meaning of "subscript ranges"? Isn't this slicing? I believe this means the range of the underlying array. For arrays on the heap, the D runtime could actually figure this out (using the same mechanism as for calculating .capacity), but of course it can't be done generally.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote: On 7/28/2018 11:18 AM, Manu wrote: Make a PR that implements namespace as a string... I will use that fork of D forever. 1. Look how it is mangled on the C++ side. (Use "grep" on the object file.) 2. Use: pragma(mangle, "the mangled name") People are trying to read C++ header files and convert the declarations ... how is that supposed to work? Even if they were manually adding declarations, this doesn't sound like a feasible approach.
Re: Struct Initialization syntax
On Tuesday, 24 July 2018 at 16:35:32 UTC, H. S. Teoh wrote:
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 attribute they refer to. And
> what of mixed cases? I really wouldn't rely on anything like
> naming conventions for something like that.
I was going to ask that how can they be named the same since
the argument would then shadow the member, but then I realized
that this works:
struct S
{ int a;
int b;
this(int a, int b)
{ this.a = a;
this.b = b;
}
}
Yes, you are right.
It works, but TBH it's quite a bad idea, and very confusing to
read.
This is a very common programming style and is found in numerous
programming books and tutorials. Personal judgments as to whether
it's a good idea or confusing are completely beside the point;
designers of struct initialization syntax should not impose such
judgments on the rest of the world, possibly forcing people to
change their code and their texts.
And TBH, if all the ctor is doing is copying its arguments to
member variables, then we really should be more DRY and have
special syntax for doing that, ala C++ (though the C++ syntax
itself is pretty pathological... D could use better syntax, but
the idea remains: get rid of redundancy like `this.a = a` or `a
= _a`).
T
This too is completely off topic. And there are hundreds of
thousands of extant lines of such code in various languages other
than C++ (or Scala, which has a different and more concise way to
avoid this boilerplate), and it hasn't been a big deal. Some
people use IDE forms/macros to fill in these common lines.
Back to the topic: I think #1 is noisy and confusing -- it looks
like a function or ctor call but isn't, and it looks like {...}
is a literal but isn't. I think #2 has to be considered in
conjunction with and dependent on named parameters. If named
parameters use the same syntax then #2 could be treated as if it
were a call to an implicit ctor that takes optional named
parameters corresponding to each member, which would provide
uniformity, but I think it's a bit dangerous and confusing, using
the same syntax to do two different things, initialization and
construction. I think #3 is straightforward, clear, and
consistent with existing struct initialization ... does it have
any downsides?
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 08:34:30 UTC, Manu wrote: [snip] It upsets me when people present strong opinions about this who literally have no horse in the race. This is only really meaningful, and only affects you if it actually affects you... It's clearly not important to you, or you wouldn't be basing your opinion on *I kinda feel...* Jonathan's argument is similar. He's worried about something that this thread has tried and failed to determine exactly what is. I don't think that's fair. He has been quite specific about his concern and the kind of situations where there would be degraded behavior, and it clearly *is* important to him, and he certainly has a horse in the race. But I believe you are correct that those are cases where there's some unrelated bug that the ref parameter restriction just happens to catch, and that's not a good enough argument for keeping the restriction. Meanwhile I think we have determined that the presumed practical trouble cases are even less that I suspected up front. That's surprising; I didn't realize that you suspected practical trouble cases.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Saturday, 21 July 2018 at 01:17:40 UTC, Jonathan M Davis wrote: On Friday, July 20, 2018 18:04:26 Manu via Digitalmars-d wrote: On Fri, 20 Jul 2018 at 18:02, Manu wrote: > [...] > > I think you're describing now a bug where a function returns > an lvalue, but it was meant to return an rvalue. Sorry, wrong way around! I meant to say: I think you're describing now a bug where a function returns an rvalue, but it was meant to return an lvalue (ie, a ref). The function returning an rvalue isn't necessarily a bug. It's the fact that it was then used in conjunction with a function that accepts its argument by ref in order to mutate it. If a function accepts its argument by ref in order to mutate it, then it's a but for it to be given an rvalue regardless of whether the rvalue comes from. It's just that some cases are more obviously wrong than others (e.g. passing foo + bad might be obviously wrong, whereas passing foo.bar may be wrong but look correct). - Jonathan M Davis If the value returned by the function is not supposed to be mutable, then the fact that the function taking the ref parameter doesn't mutate it is not a bug. If it is supposed to be mutable, then there's an unrelated bug in the function that returns the value, which just happens to get caught by the current ref parameter restriction. The only other sort of bug is where you have a value that isn't supposed to be mutated and you have no intention of mutating it, and yet you pass it to a ref function parameter the express purpose of which is to mutate it, and then you don't use the result of that mutation ... but it's hard to even see that as a bug, just a pointless exercise, and it's hard to come up with a likely scenario where this would happen accidentally. The situation is similar with a property that either isn't supposed to be mutable and you don't expect to mutate it and don't use its changed value yet pass it to a ref parameter the express purpose of which is to mutate it, or the property is supposed to be mutable but isn't and the current ref parameter restriction just happens to catch that unrelated bug. I've read this exchange carefully and so far I agree with Manu's reasoning and the value of the DIP as it stands, and I'm not in favor of requiring @rvalue, as that negates much of the intent. However, I'm a D neophyte so I could well be missing something.
Re: C's Biggest Mistake on Hacker News
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 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. It ought to be obvious that "just use better tools" is far cheaper and more effective, but I think one of the problems is something that I also see in politics quite a bit: a lot of people are more interested in feeling superior or punishing people for their flaws than in avoiding bad outcomes. And there's also the magical "if only everyone would ..." thinking. If you want to get everyone to do something they aren't currently doing, you need some *causal mechanism* (and it has to be feasible, which "avoid all mistakes through discipline" is not).
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 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: 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.
