Re: Manu's `shared` vs the @trusted promise
On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote: The @trusted contract says that an @trusted function must be safe when called from an @safe function. That calling @safe function might be located in the same module, meaning it might have the same level of access as the @trusted function. That means, Atomic.incr is invalid. It's invalid whether Atomic.badboy exists or not. It's invalid because we can even possibly write an Atomic.badboy. That's my interpretation of the spec, at least. Frankly, this does not sound credible. According to this rationale, array access should be @system too, because it relies on the array not giving direct access to its length to the user, which would also in itself be @safe.
Re: Updating D beyond Unicode 2.0
On Saturday, 29 September 2018 at 02:22:55 UTC, Shachar Shemesh wrote: I missed something he said in one of the other (as of this writing, 98) posts of this thread, and thus causing Dukc to label me a bullshitter. I know you meant Sarn, but still... can you please be a bit less aggresive with our wording?
Re: Updating D beyond Unicode 2.0
On Friday, 28 September 2018 at 02:23:32 UTC, sarn wrote: Shachar seems to be aiming for an internet high score by shooting down threads without reading them. You have better things to do. http://www.paulgraham.com/vb.html I believe you're being too harsh. It's easy to miss a part of a post sometimes.
Re: Updating D beyond Unicode 2.0
On Wednesday, 26 September 2018 at 07:37:28 UTC, Shachar Shemesh wrote: The other type of answer is "it's being done in the real world". If it's in active use in the real world, it might make sense to support it, even if we can agree that the design is not optimal. Shachar Two years ago, I taked part in implementing a commerical game. It was made in C# (Unity) but I don't think that matters, since D would have faced the same thing, were it used. Anyway, the game has three characters with completely different abilites. The abilites were unique enough that it made sense to name some functions after the characters. One of the characters really has a non-ASCII character in his name, and that meant naming him differently in the code.
Re: Updating D beyond Unicode 2.0
On Wednesday, 26 September 2018 at 06:50:47 UTC, Shachar Shemesh wrote: The properties that cause city names to be poor candidates for enum values are the same as those that make them Unicode candidates. How so? City names (data, changes over time) as enums (compile time set) seem like a horrible idea. In most cases yes. But not always. You might me doing some sort of game where certain cities are a central concept, not just data with properties. Another possibility is that you're using code as data, AKA scripting. And who says anyway you can't make a program that's designed specificially for certain cities?
Re: Updating D beyond Unicode 2.0
When I make code that I expect to be only used around here, I generally write the code itself in english but comments in my own language. I agree that in general, it's better to stick with english in identifiers when the programming language and the standard library is English. On Tuesday, 25 September 2018 at 09:28:33 UTC, FeepingCreature wrote: On Friday, 21 September 2018 at 23:17:42 UTC, Seb wrote: In all seriousness I hate it when someone thought its funny to use the lambda symbol as an identifier and I have to copy that symbol whenever I want to use it because there's no convenient way to type it. (This is already supported in D.) I just want to chime in that I've definitely used greek letters in "ordinary" code - it's handy when writing math and feeling lazy. On the other hand, Unicode identifiers till have their value IMO. The quote above is one reason for that -if there is a very specialized codebase it may be just inpractical to letterize everything. Another reason is that something may not have a good translation to English. If there is an enum type listing city names, it is IMO better to write them as normal, using Unicode. CityName.seinäjoki, not CityName.seinaejoki.
Re: Small @nogc experience report
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: Not Weka but we are happy with @nogc and without @nogc our job would be impossible. There is one way to code without garbage collector somewhat practically without annotating @nogc, the way I use: Compile manually only those parts of runtime you need and have linker to link in only needed symbols (so there is no need to go stubbing the whole runtime). If you accidently allocate, you get linker errors. Still, @nogc helps because it will tell right away where I called something I should not. I wonder if having an option to compile DRuntime without support for thearding would simplify portability. I once read the implementation and got the impression that theards are by far the most platform-dependant part of it.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
// D
auto a = "á";
auto b = "á";
auto c = "\u200B";
auto x = a ~ c ~ a;
auto y = b ~ c ~ b;
writeln(a.length); // 2 wtf
writeln(b.length); // 3 wtf
writeln(x.length); // 7 wtf
writeln(y.length); // 9 wtf
writeln(a == b); // false wtf
writeln("ááá".canFind("á")); // false wtf
I had to copy-paste that because I wondered how the last two can
be false. They are because á is encoded differently. if you
replace all occurences of it with a grapheme that fits to one
code point, the results are:
2
2
7
7
true
true
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 22:04:49 UTC, H. S. Teoh wrote: I don't know how to reconcile these two. Perhaps if we had the manpower, we could maintain older versions for long enough to allow users to gradually rewrite to work with newer compilers, while the development branch can be bolder in making breaking changes that ultimately will result in a better, cleaner language. But I doubt we have the kind of manpower it takes to maintain something like that. In theory, it should be done so that there would be a longer-term unstable and and stable major branches. Stable major branch would behave mainly like we do now: new features allowed and breaking changes also allowed, but only with proper deprectation processes. In unstable major branch, you would do breaking changes, like removing autodecoding and exception throwing on general-purpose Phobos functions. No additional features here unless they depend on the breakages, to ease transitioning between the two. Thwy would be merged like perhaps every ten versions. I'm not saying this would necessarily work, but in theory it's the only way to get rid of historical babbage without becoming a moving target.
Re: D is dead
On Thursday, 23 August 2018 at 04:44:47 UTC, Shachar Shemesh wrote: But, again, it is interesting to see what you took from my mail. I think the biggest problem is lack of reviewers when making PR:s. The fact that we have D language foundation, state of D survey, extensive autotester and regular release schelude seem to imply, for me, that much more than ADD is being done. But then again, my D projects so far are too small that I could really know where the problems are. It may be that in time, if they grow, I start to agree with you.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. And by "fatal", I mean literally flaws that are likely to literally kill the language. How so? If he's right with those issues, they can definitely prevent D from becoming mainstream, but how would they kill D? I mean, will not there always be some existing users who have no need or wish to move on?
Re: High-level vision for 2018 H2?
On Thursday, 16 August 2018 at 14:11:20 UTC, Andrei Alexandrescu wrote: we're working on a HOPL submission. What's HOPL?
Re: Friends don't let friends use inout with scope and -dip1000
On Friday, 17 August 2018 at 13:39:29 UTC, Steven Schveighoffer
wrote:
On 8/17/18 3:36 AM, Atila Neves wrote:
Here's a struct:
-
// used to be scope int* ptr() { return ints; }
scope inout(int)* ptr() inout { return ints; }
Does scope apply to the return value or the `this` reference?
This reference. putting it like:
inout(int)* ptr() inout scope { return ints; }
...does not change anything.
Another thing it should AFAIK catch but doesn't:
import std.stdio;
@safe:
struct MyStruct {
int* intP;
this(int val) { intP = new int(val); }
int* ptr() return scope { return intP; }
}
int *gInt;
void main() {
auto s = MyStruct(10);
gInt = s.ptr;
writeln(*gInt);
}
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Saturday, 11 August 2018 at 10:04:14 UTC, Nicholas Wilson wrote: On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote: The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex. I disagree. I have no doubt you know more about compiler internals than me so not arguing about that. Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer. Of what _practical use_ is that? Tried to come up with an example but it would be so far-fetched that it won't be a reason in itself to add a new feature. I have to start to think longer before I post.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Saturday, 11 August 2018 at 05:01:50 UTC, docandrew wrote: On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote: A better name for this type is `never`, which is the name of the TypeScript type with similar semantics. https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing. +1 for "never" - it's descriptive and readable. -Jon And brings us closer to Rust, which is a good thing. But it does not matter, since the PR isn't suggesting any name for it -the user can create any alias of it he/she wants. Personally, I think the most accurate term would be "Paradox" but again it does not matter for sake of this DIP.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote: meant is(typeof(*null) == typeof(assert(0))) How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error nodes in the AST, only assert(0) is considered special under this DIP. Granted, an example like that should be described so we know better what he means with the possible future uses. The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex. Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Friday, 10 August 2018 at 11:28:38 UTC, Dukc wrote: One example comes to mind: is(typeof(null) == typeof(assert(0))). meant is(typeof(*null) == typeof(assert(0)))
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote: * "[With @noreturn] other potential uses of a bottom type will not be expressible". What other? Documentation and optimisation definitely can be, the are in LDC since a long time, there are no other substantiated benefits listed in the DIP. One example comes to mind: is(typeof(null) == typeof(assert(0))).
Re: Struct Initialization syntax
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.
Re: Struct Initialization syntax
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 them. But there might be some corner cases where this would not apply. Do you see any?
Re: C's Biggest Mistake on Hacker News
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 from C code to D is easy, because you can slice pointers just like arrays -it's just that it won't be bounds checked.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 23:19:08 UTC, Nicholas Wilson wrote: On Friday, 20 July 2018 at 16:39:46 UTC, Dukc wrote: How so? It could be made it act exactly as if the temporary was made just before the function call, meaning the lifetime would end at the end of current scope. ... which is exactly what this DIP proposes ... ... except the compiler would do that only when appending .byRef. Of course, this required compiler magic. A library solution would have exactly the limits you said. ... and why its a DIP, and not a phobos PR. With that I agree.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote: appending something (like .byRef or byRef!long, the latter making an implicit type conversion) That can't work: either it returns an expired stack temporary (*very* bad), or allocates with no way to deallocate (bad). How so? It could be made it act exactly as if the temporary was made just before the function call, meaning the lifetime would end at the end of current scope. Of course, this required compiler magic. A library solution would have exactly the limits you said.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 09:24:19 UTC, Bastiaan Veelo wrote: On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote: Thanks for the effort to make it... I believe Manu will be pleased. Manu is the one who wrote the DIP :-) Though it was Mike :-)
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values" I'd prefer a solution which allows one to make an invisible temp manually without making a new statement or a new symbol name. By appending something (like .byRef or byRef!long, the latter making an implicit type conversion) after a rvalue statement. This would still prevent things like byRefFunction(aVariable.incremented) when incremented copies the value without the user excepting it. But If the options are either your solution or the present situation, yours is still better. Thanks for the effort to make it... I believe Manu will be pleased.
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On Thursday, 12 July 2018 at 10:38:52 UTC, Shachar Shemesh wrote: On 12/07/18 04:17, Jonathan M Davis wrote:> I'm also> not sure if going to copy constructors means that we should do something> different with this. It don't think that it's affected by it, but I could be> missing something. I actually had that very same concern myself. Andrei does not seem to share it (I talked to him about it during DConf, and he even mentioned it in his talk). He seems to think the two are completely independent. That's already thought through? Great, no need to "lockstep" the DIPs then and one curve less to worry about.
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On Thursday, 5 July 2018 at 10:27:52 UTC, Dukc wrote: The DIP looks well written. I'm in favour of it. However, we need to consider how well this interacts with Razvan's DIP [1]. We should consider this together with it, so the implementations do not end up messing each other. 1: https://forum.dlang.org/thread/hhdtliynfwckcgafl...@forum.dlang.org
Re: Alternative destructors, do/should we have them?
On Thursday, 5 July 2018 at 16:12:08 UTC, Atila Neves wrote:
On Thursday, 5 July 2018 at 10:57:51 UTC, Dukc wrote:
D does not have default constructors for structs, but I have
thought that this might get around the problem:
[...]
You already have that capability:
struct HandGrenade {
void* ptr;
void destroy() {
import core.stdc.stdlib: free;
free(ptr);
}
}
This isn't a great example since it's perfectly fine to pass
null to core.stdc.stdlib.free.
Atila
On Thursday, 5 July 2018 at 16:12:08 UTC, Atila Neves wrote:
This isn't a great example since it's perfectly fine to pass
null to core.stdc.stdlib.free.
Atila
You're right. Well, It could be some custom allocation table that
does not check for such things:
struct HandGrenade
{void* ptr;
~this()
{ foreach
( ref _byte;
cast(ubyte[]) ptr[0 ..
memoryTable.assumeSorted.upperBound(ptr).front - ptr]
) _byte = 0;
}
}
Re: Alternative destructors, do/should we have them?
On Thursday, 5 July 2018 at 15:58:14 UTC, Andrea Fontana wrote: On Thursday, 5 July 2018 at 10:57:51 UTC, Dukc wrote: If not, should we in your opinion have an ability to define an alternative destructor which runs only when explicitly requested? What does "when explicity requested" mean? That the alternative destructor runs only when you ask it to. There would be some way to say before an end of a block, return statement, break statement ect that you want the alternative destructor to be applied to the struct. The normal destructor would not run when an alternative one is used, but would run otherwise. In fact, in this case it would be enough to elide the destructor somehow.
Re: dmd optimizer now converted to D!
On Thursday, 5 July 2018 at 12:50:18 UTC, Ivan Kazmenko wrote:
Is there any better way? To prevent introducing bugs when
micro-optimizing, I'd like the loop body to remain as unchanged
as it can be.
foreach(j, ref piece; cast(int[4][]) a)
{ auto pieceI = j * 4;
static foreach(i; 0 .. piece.length) piece[i] = pieceI + i;
}
Can probably be made even better by designing some template
helper.
Alternative destructors, do/should we have them?
D does not have default constructors for structs, but I have
thought that this might get around the problem:
struct MallocedPtr()
{ void* location;
~this()
{ import core.stdc.stdlib;
assert(location != null);
free(location.ptr);
}
}
Unlike a destructor which has a runtime check whether it's
initialized, this has no performance cost over a C++-style
default-initialized struct. I think "hand grenade RAII" is a
perfect name for this idiom, because like a hand grenade, this
struct asserts it is set somewhere else after initialization
before it's destructor runs.
But there is a problem. If you use std.algorithm.move to give a
hand grenade to a function, it initializes another hand grenade
for the calling function. I didn't come up with any way to defuse
the initialized grenade without runtime cost.
Granted, a runtime check at destructor is unlikely to be a major
performance hit for any normal application, but D is a systems
language, right? Do you have any ideas to get around this? If
not, should we in your opinion have an ability to define an
alternative destructor which runs only when explicitly requested?
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: DIP 1014, "Hooking D's struct move semantics", is now ready for final review. Structs are a low level feature that should be able to be used in any way programmer sees fit. This is just what is wrong with C# structs: In principle they're the same as D structs but disallow many things for no obvious reason, thus limiting their usability. See my question and it's answers at Stack overflow to see what I mean: https://stackoverflow.com/questions/51098690/assigning-value-to-member-of-nullable-struct-in-c-sharp This is a feature that is likely to be useful for low level programming, but is zero cost for those who don't need it. The DIP looks well written. I'm in favour of it.
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Sunday, 17 June 2018 at 20:17:36 UTC, Dukc wrote: Yes, I agree. And each too, of course. Thought again and not so sure anymore: I just realized that if we are to do that, it should apply the same changes to tee, find, filter etc. Probably too complicated to be worth it. For @nogc, there's also always hope that we will be able to mark delegates scope, and with -dip1000, use local variables directly again.
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Sunday, 17 June 2018 at 13:50:31 UTC, Seb wrote: On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote: What are your thoughts? Do you agree with this coding pattern? It would even be better if map can recognize tuples and thus allows to simply use a lambda functions with two parameters, but in the past with a few exceptions there hasn't been much support/consensus on specializing Phobos functions for tuples. Yes, I agree. And each too, of course.
An (old/new?) pattern to utilize phobos better with @nogc
I think I have just found a pattern to ease the pain of @nogc
programming somewhat. Consider this:
import std.algorithm;
import std.range;
@nogc void main()
{ import core.stdc.stdio;
int power = 2;
foreach
( raised;
iota(10)
.dropOne
.map!(num => num^^power)
) printf("%d\n", raised);
}
It won't compile, because the lambda argument on map uses the
local variable power. Compiler thinks it must allocate that
variable in heap, using gc, lest the lambda function could
overlive power.
So that is probably one big reason for complains about Phobos
when you can't use the garbage collector. This hurdle won't make
it useless, though. You can avoid the problem this way:
import std.algorithm;
import std.range;
@nogc void main()
{ import core.stdc.stdio;
int power = 2;
foreach
( raised;
iota(10)
.dropOne
.zip(power.repeat)
.map!(arg => arg[0]^^arg[1])
) printf("%d\n", raised);
}
It works, but arg[0] and arg[1] are fairly much book examples on
how to NOT name your variables.
But with a little bit of help, the library can still do better:
import std.algorithm;
import std.range;
@nogc void main()
{ import core.stdc.stdio;
int power = 2;
foreach
( raised;
iota(10)
.dropOne
.zip(power.repeat)
.map!(tupArg!((num, pow) => num^^pow))
) printf("%d\n", raised);
}
alias tupArg(alias func) = x => func(x.expand);
Yes, it makes the syntax heavier, and in a simple case like this
it's arguable whether it's worth it.
But for me at least, when the complexity of the map alias
parameter starts rising, having the ability to name your
variables definitely pays back.
What are your thoughts? Do you agree with this coding pattern?
Re: Morale of a story: ~ is the right choice for concat operator
On Saturday, 26 May 2018 at 12:37:15 UTC, rumbu wrote:
Therefore your first example will work correctly if you convert
the int result back to char: (char)('a' + 'b') + "s" will
render the correct result.
Even if C# would use '~' instead of '+', you had a type
conversion problem, not an operator problem, you wrongly
assumed that adding two chars will result in a char, not an
int. In the hypothetically code 'a' + 'b' ~ "s" is also
"195s".
I had to go back and check. Yes, it appears I screw up here.
Sorry.
Sigh, this is one of the cases whereI wish I could edit my posts.
Re: Morale of a story: ~ is the right choice for concat operator
On Saturday, 26 May 2018 at 11:04:44 UTC, Nick Treleaven wrote: I don't think it makes sense to allow adding two characters - the second operand should be an integer type. So it would behave like pointer arithmetic. Sounds sound. Not for D because of the C semantic similarity requirement but for some other aspiring language.
Re: Morale of a story: ~ is the right choice for concat operator
On Saturday, 26 May 2018 at 09:01:29 UTC, rumbu wrote: Sorry, but the mistake here is the fact that you wrongly assume C behavior in C#. Yes it is. But that does not make differentiating concat and addition in language desing any less worthwhile. In car crashes, the mistake is usually made by a driver, but I know no-one who says safety belts aren't worthwhile. Adding chars to an existing string will result in a string as in the language specification. In fact I didn't make the mistake there. What surprised me was that adding two INDIVIDUAL chars result in a string. When op+ is srictly for mathematical summing, there are no ambiquites.
Re: Morale of a story: ~ is the right choice for concat operator
On Friday, 25 May 2018 at 23:57:03 UTC, IntegratedDimensions wrote: So, you think by forcing programmers to use a break, goto, or return at the end of a case somes errors but really what it does it make programmers less aware of the problems. They become less effective programmers in the long run. If you have a child, for example, and you always throw them in the pool with maximum amount of safety gear they never really learn to swim. You are trying to protect them from a *potential* problem but cause a real problem in stead. It is impossible to swim correctly with "floaties" because they change the physics and also offer a false sense of security. You're confusing two things here. Yes, if we never use void[] casts, pointers, goto statements ect, or at least study how they work, we're gonna be helpless. But D does not prevent using them, just makes you aware when you do. For sure you won't learn to swim correctly with plastic pillows only, but that does not mean they have to be made so that they could break at any moment. It just means you have to take them off sometimes.
Re: On Forum Moderation
On Saturday, 26 May 2018 at 03:34:50 UTC, Walter Bright wrote: For unprofessional demeanor, I recommend reddit. Wat?!?
Re: Morale of a story: ~ is the right choice for concat operator
On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote: This ambiguity bug with + has been causing well-known problems since Algol. A *really* long time. Yet it gets constantly welded into new languages. Yeah. I could understand that choice for a language that tries to be simple for beginners above everything else. But for large-scale application language like C#, I quess this just did not occur to them.
Morale of a story: ~ is the right choice for concat operator
I was programming in C# and wanted to format an int in
hexadecimal. It may be that I should have used some library
function for that, but I decided to roll my own function for that
anyway, in my general utility class:
public static string FormatHexadecimal(int what)
{ if (what == 0) return "0";
string result = "";
bool signed = what < 0;
if (signed) what = -what;
for (;what != 0;what >>= 4)
{ int digit = what & 0x000F;
result = (digit < 10? '0' + (char)digit: 'A' + (char)(digit -
10)) + result;
}
return signed? "-" + result: result;
}
Looks correct, right? Yes.
But quess what? Op+ has a double meaning in C#, depending on
context it means either addition or string concatenation. If you
add two characters, it interprets it as a concatenation that
results in a string with two charactes. The correct way to do
what I tried is:
public static string FormatHexadecimal(int what)
{ if (what == 0) return "0";
string result = "";
bool signed = what < 0;
if (signed) what = -what;
for (;what != 0;what >>= 4)
{ int digit = what & 0x000F;
result = (char)(digit < 10? (int)'0' + digit: (int)'A' +
(digit - 10)) + result;
}
return signed? "-" + result: result;
}
You can imagine me confused when the first version returned way
too long and incorrect strings. Now, if I were programming in D,
this would not have happened. Using + always means an addition.
If one wants to concatenate, ~ is used instead.
So, ~ may be a bit confusing for newcomers, but there is a solid
reason why it's used instead of +, and it's because they have a
fundamentally different meaning. Good work, whoever chose that
meaning!
Re: Support alias this in module scope?
On Thursday, 24 May 2018 at 07:07:48 UTC, Jonathan M Davis wrote: It's true. Should somebody of us make an Announce theard out of this?
Re: Support alias this in module scope?
On Wednesday, 23 May 2018 at 12:32:50 UTC, Steven Schveighoffer wrote: and in others he has impersonated WalterBright as well. -Steve Sorry forgot that part in my last post. If that's true, it makes it VERY serious.
Re: Online impersonation
On Wednesday, 23 May 2018 at 17:31:40 UTC, Steven Schveighoffer wrote: The IP address is included in the headers of the newsgroup. All of them came from the same IP. I have a filter on my thunderbird client to flag certain IPs, and his was added to the list recently. Then again, it's possible they're family members or neighbours using the same IP. How likely this is, I won't comment. I don't this is a case of inpersonation if you're right, since the aliases have not been trying to inpersonate any real, exact person. But dishonourable action nonetheless.
Re: Support alias this in module scope?
On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote: alias this ¤%[&Off; // <-- symbols are now aliased where they I think it could be with (¤%[&Off): also.
Re: Sealed classes - would you want them in D?
On Tuesday, 15 May 2018 at 06:38:04 UTC, KingJoffrey wrote:
Can you give me some examples?
Defining a Voldemort type (meaning, one whose name is not public)
with private members for use by multiple functions:
---
module two_functions;
private struct MyForwardRange
{ private int function(int[]) cumulator;
int[] front;
void popFront()
{ front ~= cumulator(front);
}
enum empty = false;
auto save()
{ return this;
}
}
auto accumulate(int a, int b)
{ import std.algorithm;
return MyForwardRange(arr => arr.sum, [a, b]);
}
auto extendByIota(int[] startElems)
{ return MyForwardRange(arr => arr.length, startElems);
}
---
In a simple module like this, it would be needless complexity to
make cumulator have a package visibility and put the functions in
a different module. That's what you would have to do if private
meant private to class, not to module.
Re: Sealed classes - would you want them in D?
On Monday, 14 May 2018 at 07:59:06 UTC, Jonathan M Davis wrote:
On Monday, May 14, 2018 07:03:35 Dukc via Digitalmars-d wrote:
On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:
module test;
void main() { foo.i = 2; }
void foo() { static int i = 1; }
If that's what you want, just make it a module-level variable.
Well, personally I don't care much because using static mutables
sucks anyway, and there is rarely a reason to make static
immutables just for one function. Enums are for that.
Just pointed out that it would be consistent with how classes
encapsulate stuff. And the same point goes for eponymous
templates, of course.
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 15:48:53 UTC, KingJoffrey wrote:
On Saturday, 12 May 2018 at 13:38:18 UTC, Walter Bright wrote:
Mike's right. D's encapsulation model is designed around the
module.
Actually, that is not true. If it were true, then I could do:
module test;
void main() { i = 2; } // sorry, but i belongs to another unit
of encapsulation
void foo() { int i = 1; }
No, it would be like:
module test;
void main() { foo.i = 2; }
of encapsulation
void foo() { static int i = 1; }
...and I think there might be point in allowing that.
Non-static members could also perhaps be accessed in case of
fibers, but that would likely be tough to implement and/or
complicate the runtime.
Re: Sealed classes - would you want them in D?
On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:
module test;
void main() { foo.i = 2; }
of encapsulation
void foo() { static int i = 1; }
meant
module test;
void main() { foo.i = 2; }
void foo() { static int i = 1; }
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:
...
// constructor of DataStructure
this(Allocator alloc=__ALLOC__) {...}
...
auto alloc = new SomeAllocator();
define __ALLOC__ = alloc;
// And we don't need to pass alloc everytime
...
Is this a good idea?
Doesn't this basically mean including the implicits Martin
Odersky talked about at Dconf in D?
I don't know whether it's a good idea all-in-all, but assuming
the arguments can be used as compile-time I can already see a big
use case: killing autodecoding without breaking code. Something
like:
auto front(C, bool disableDecoding = __NODECODE__)(inout C[]
string)
{ static if (disableDecoding) {...}
else {...}
}
Re: Sealed classes - would you want them in D?
On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote: On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote: `private` is for outside the module. Within the module, private is not applied because D wanted to avoid C++'s `friend` functions. 'private' is "meant" to be part of the implementation of 'the class'. Whereas D makes it part of the implementation of 'the module' ( which is an even higher level of abstraction). This is an abomination! A class should have the capacity to protect its attributes/methods - even from the module. You can use D private with Java-like "only for members functions" meaning by putting it alone in it's module, if you want.
Re: DIP 1013: The Deprecation Process -- Community Review Round 1
On Monday, 2 April 2018 at 07:05:45 UTC, Mike Parker wrote: [snip] I like this. A goto-reference as of how and when to deprectate and remove. About the concerns that depractation period being measured by releases could fluctate the interval, I definitely would have agreed in autumn 2016. But now we have the release progress in place so I think it will go predictably enough. Nonetheless, I think that maintainers must always retain the liberty to disregard these rules when there's a very good reason. If there, for example, starts to be much larger slips in release schelude again they should be able to go ahead and remove stuff early.
Re: [OT] Unity migrating parts of their engine from C++ into High Performace C# (HPC#)
On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote: - No code that would trigger GC is allowed Impressive! It definitely won't be anyhing like D or Rust in systems field anyway, but C# usually feels to be so reliant in GC that this sounds wonderous nonetheless! Especially if, even without its core feature, classes, it's worthy as a c++ replacement where applicable. I should really check this at some point.
Re: Why not flag away the mistakes of the past?
On Wednesday, 7 March 2018 at 16:29:33 UTC, Seb wrote: Well, I tried that already: https://github.com/dlang/phobos/pull/5513 In short: very easy to do, but not much interest at the time. No. The main problem with that (and the idea of using a compiler flag in general) is that it affects the whole compilation. That means that every single third-party library, not only Phobos, has to work BOTH with and without the switch. IMO, if we find a way to enable or disable autodecoding per module, not per compilation, that will make deprectating it more than worthwhile.
Re: Interesting article from JVM world - Conservative GC: Is It Really That Bad?
On Monday, 5 March 2018 at 05:43:36 UTC, Ali wrote: i think he means this article https://www.excelsiorjet.com/blog/articles/conservative-gc-is-it-really-that-bad/ https://news.ycombinator.com/item?id=16436574 Thank you.
Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529
I don't think a just iterated array is automatically set to null, so taking it's pointer won't hit a memory-proteted area. So undeprectating arr.ptr in @safe would break @safety and be a step backward. If this is an issue, one can define a @trusted function which takes a starting pointer from array and casts it to size_t before returning it so memory corruption cannot happen via it. On Tuesday, 27 February 2018 at 09:47:51 UTC, Stefan Koch wrote: Checking if an array is the slice of another. For that there is also std.array.overlap().
Re: Knowing the approach to solve a D challenge
On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? In micro-level, it's usually fairly idiomatic from get-go. Usually no heap allocations at inner loops, for-looping, static variables etc. Sometimes if I get a bit desperate of frustated I might do this a bit. But at larger level, I often find myself shifting work between functions, structs, modules and so. In other words, redesigning. 2. Do you find yourself mostly rolling out your own implementation first before using a library function? No, the vast majority of my calls are from Phobos or other libraries I use. And in case of Phobos at least, it's stuff is so general that I don't need to design my own function often. An exception is std.algorithm.each, but just to get better error messages (template constraints don't tell why the call did not work). 3. Do the use of generics come out of first try or a rewrite? Rewriting a lot, but that's the case with all coding. With generics, i often tend to forget ! before an alias parameter. 4. What rough percentage of phobos knowledge is required for reasonable good problem solving efficiency? If we talk about experience of the language in general, it's more than with C-style programming, Java or C# but less than with C++ generics. I don't think you have to know Phobos throughout, but you have to know the language and understand the philosophy of ranges quite deeply. Percentages aren't important, I think that as long as you know the general purpose of std.algorithm, std.range, std.stdio, std.conv and std.array that gets you started. Again, if you know the language and understand the range concept.
Re: Being Positive
On Tuesday, 13 February 2018 at 07:47:39 UTC, JN wrote: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." Wasn't that from Bjarne Stroustrup?
Re: Being Positive
On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran wrote: Sorry if I'm hurting someone's sentiment, but is it just me who is seeing so much negative trend in the D forum about D itself? Well, programmers are engineers, and engineers tend to focus on things that need improvement. That has the downside that the attitude might stealthily get negative. That is likely to be the base reason. Too positive an attitude in a wrong woy would stall the development. That does not mean negativity is desirable, just that it's sometimes hard to say what's constructive criticism and what's complaining. I don't remember seeing so much negative about Rust on rust forum and so on. I don't feel the general attitude to be negative, I think many people are very positive here: Andrei, Ali and H.S.Teoh are excellent examples. And those who sound negative at times are being constructive. It's true there are rant posts that fail to keep a good attitude, but I think they are usually from "outside" people. Regular D users are almost always reasonably nice.
Re: A betterC base
On Friday, 9 February 2018 at 21:24:14 UTC, Walter Bright wrote: Of course, the issue can get more complex. GC uses 3x the memory of RC, and so you can get extra slowdowns from swapping and cache misses. Is the total memory consumption tripled, or only the extra memory used for tracking allocations?
Re: Which language futures make D overcompicated?
On Friday, 9 February 2018 at 18:31:18 UTC, H. S. Teoh wrote: TBH, I'm not a fan of inout. Not because of how most people feel, that we shouldn't have it; IMO it doesn't go *far enough*. For example, there's currently no way to express conveying the constness of a delegate argument's parameter to the return value, which would have been useful in some places in generic code. So it's in your list of wanted stuff, not in your list of excess stuff. We're in agreement here. What I would like to remove, is auto-decoding (popular opinion, I know) I would totally back up killing auto-decoding. With fire. And extreme prejudice. :-P barring some kind of workable (probably very long) deprecation cycle, I just don't see it going away anytime in the foreseeable future. If we had something similar to c++ template lookup, it would, as I see it, finally solve that, along with many other problems. But bring some others, it's said... Better wrapper writing way than alias this would also solve it mostly and without the ADL problems, but there would still remain a problem with string and char literals. __traits, is expression, typeof and std.meta templates should be invokable in a more UFCS-like manner As for is-expressions, I think either Walter or Andrei (possibly both) have acknowledged that the syntax is a mess. But too much code already depends on the current syntax, and changing that now will be far too disruptive. But UFCS style also allows the traditional way, there would be no breakage. So I quess that even here the existing thing is there for a reason after all. After reading Manus list, I think I agree with his point 1.
Re: Which language futures make D overcompicated?
On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote: Which language futures by your opinion make D harder? Not many! D is a fairly complex languague, but just about everything feels like to be here for a good reason. That includes many oft-hated things: inout, auto ref, goto, BetterC... What I would like to remove, is auto-decoding (popular opinion, I know) and the heavy syntax when handling types: __traits, is expression, typeof and std.meta templates should be invokable in a more UFCS-like manner (But still avoiding context-dependant parsing, perhaps with a keyword before an expression used as a type in a declaration).
Re: A few Phobos projects: @safe, dip1000, public examples, properly documented functions, ...
On Monday, 29 January 2018 at 17:51:40 UTC, Seb wrote: - All high-level code should be usable in @safe This is not currently possible with functions that take a delegate parameter, including opApply. (without sacrificing genericity) A DIP could be made so that the function infers it's attributes from a delegate argument, but that's so much added complexity that it's debatable whether it would be worth it.
Vision for 2018 H1?
Is it intended to be updated? No pressure, just making sure it's not forgotten...
Re: __traits(documentation, X)
On Wednesday, 17 January 2018 at 02:19:11 UTC, Seb wrote: So do you have a good use cases for this? If this is a useful feature, the implementation can be improved to be zero-cost for normal runs. If a GUI button simply executes a function. Tooltip for it could be generated from the function documentation. About being able to use the documentation comment in mixins, of course it would be an ill recommended thing to do. But I don't think it would become much of an issue since you can hardly do that accidently. IMO, D can already be used more dangerously than even C++ if you want to: binary imports, string mixins and static ifs can be used for far more sophiscated hacks than the C preprocessor. But it does not matter since they do not encourage or trick anybody to do the said hacks.
Re: The name "Phobos" in user-facing docs
On Friday, 12 January 2018 at 21:24:40 UTC, John Gabriele wrote:
1. It has its own name. Phobos. This is unusual. I don't know
of any other language who's std lib has any name other than
"the {lang} standard library". Why does it have its own
distinct name, and why do I (as a user) need to know it?
Because Walter Bright's company is named Digital Mars, D was
initially named "Mars programming language". I am fairly certain
that's the original reason for the name of the library. After
all, why change it now when it's in common use? Where I live we
have a saying: "A dear child has many names".
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: Another issue is I've had the flu for a while which makes me tired, and then it's best to work on things that don't require much mental energy. I quess that applies easily twice as strongly if you code bigger things on the run, no? :D
Re: state of ranges
On Wednesday, 13 December 2017 at 10:15:10 UTC, ag0aep6g wrote: `front` can't assume that `empty` has been called before. For a well-behaved range, `front` must work the same whether you've called `empty` or not (given that the range isn't actually empty). That last point is what I meant: it cannot assume empty() being called BUT it can assume that it WOULD have returned false it it were. So there is no problem with the program crashing when calling front() of an empty range. Therefore, there is no need to manually do stuff like if(inited) because if the elements are not initialized, the range would obviously be empty. Assuming I understood the intention of that code correctly.
Re: state of ranges
On Tuesday, 12 December 2017 at 23:43:19 UTC, Luís Marques wrote: Well, I was referring to things like in front() having to use code such as `if(!inited) ...; return value I think you only have to do that if you have some custom pointer arithmetic and you want to make sure it remains memory safe. However, in the general case you don't need to do that. front() can assume that something can be found, so it may as well fetch the value without checking and rely on built-in array bounds checking and null behaviour for memory safety. empty() is the one which should check those things manually.
Re: First Impressions!
On Tuesday, 28 November 2017 at 16:14:52 UTC, Jack Stouffer wrote:
you can apply attributes to your whole project by adding them
to main
void main(string[] args) @safe {}
Although this isn't recommended, as almost no program can be
completely safe.
In fact I believe it is. When you have something unsafe you can
manually wrap it with @trusted. Same goes with nothrow, since you
can catch everything thrown.
But putting @nogc to main is of course not recommended except in
special cases, and pure is competely out of question.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Monday, 20 November 2017 at 10:45:20 UTC, Dukc wrote: A type that wraps a reference type behaving like a value type. Default initialized value and what to do on copy would be passed as template parameters. Perhaps I should try... Just realized Unique!T is already pretty close. A few (non-breaking) modifications on it could do the trick.
Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Sunday, 19 November 2017 at 04:04:04 UTC, Walter Bright wrote:
Interestingly, `int` isn't nullable, and we routinely use
rather ugly hacks to fake it being nullable, like reserving a
bit pattern like 0, -1 or 0xDEADBEEF and calling it
INVALID_VALUE, or carrying around some other separate flag that
says if it is valid or not. These are often rich sources of
bugs.
As you can guess, I happen to like null, because there are no
hidden bugs from pretending it is a valid value - you get an
immediate program halt - rather than subtly corrupted results.
I don't deny these. Null is an excellent way to denote "empty" or
"invalid". Thats just what std.typecons.Nullable!T is for.
Granted, it is not quite as elegant as naturally nullable types.
But that does not mean nullables are always good. Consider:
struct TimeOfDay
{ byte hours
byte minutes
byte seconds
}
While it might make sense to make the TimeOfDay nullable as
whole, you definitely do not want all the fields have a null
value each. You know statically that if the struct is valid, then
all it's members are valid.
It would be only a performance slowdown to check for null with
them. You could skip those null-checks by convention but for sure
you would not always remember, causing sub-optimal performance.
Ideally you would want to leave it up to the type user whether
you have a null value or not, just like C# does. Whether it's
worth it's weight is a different question through.
About the question what should be default-initialized value for
an abstarct type were it non-nulllable, I think the type definer
should decide that. A library solution here would sound credible
to me. A type that wraps a reference type behaving like a value
type. Default initialized value and what to do on copy would be
passed as template parameters. Perhaps I should try...
Re: DConf 2018 Logo
On Thursday, 16 November 2017 at 23:03:10 UTC, H. S. Teoh wrote: For an official logo, though, I'd expect something more refined. The concept itself seems workable. T Unfortunately, I'm no artist. It would probably look worse if I tried to refine it much from that.
Re: DConf 2018 Logo
On Wednesday, 15 November 2017 at 14:56:53 UTC, Andrei Alexandrescu wrote: Hello, for all of you with expertise in graphics, we'd be in your debt if you could create a logo for DConf 2018. Proposals would be appreciated! Thanks, Andrei Probably too crude to be worth considering but feel free to use it as base if here's someone who wan't to imporove it. https://imgur.com/a/eU4Id
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote: For example, suppose you're using a proprietary library that provides a class X that behaves pretty closely to a range, but doesn't quite have a range API. (Or any other API, really.) Well, that's not a problem, you just write free functions that forward to class X's methods to bridge the API gap, and off you go. You don't have to work with your upstream provider, who may not be able to provide a fix until months later, and you don't have to create all sorts of wrapper types just to adapt one API to another. Yes, the idea here is great. It will work with range functions you define. The problem is, it won't work with Phobos functions because they do not see your extensions to that proprietary type. They see only the true member functions of it. Unless you hack phobos and add your extensions to that propietary library there, which would be a very ugly solution. You can of course wrap that proprietary range type but that is a lot of manual work and requires maintenance. Alias this solves some cases but not all of them. I am not sure what would be the best way for the language to handle this but for sure not the present way. The idiom is otherwise so great.
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On Thursday, 26 October 2017 at 12:19:33 UTC, Steven
Schveighoffer wrote:
D's lookup rules fail miserably when it comes to templates:
mod1.d:
auto callFoo(T)(T t)
{
return t.foo;
}
mod2.d:
struct S
{
int x;
}
int foo(S s) { return s.x * 5; }
void main()
{
auto s = S(1);
assert(s.foo == 5);
assert(s.callFoo == 5); // can't compile
}
Would be nice to have a way around this. Not sure what it would
look like.
Assuming you don't want to change the original struct, this can
be worked around by making a wrapper type using alias this. I
think that's logical because you have to be explicit about which
foreign functions you want the imported algorithm to see. There
would be a function hijacking problem otherwise.
What is the catch here, is that alias this won't solve cases
where the free function takes a reference to the wrapped type or
returns it.
Re: What is the Philosophy of D?
On Wednesday, 18 October 2017 at 12:25:57 UTC, Ola Fosheim Grøstad wrote: I don't think C# force you to use object oriented modelling? Clearly the GC and the standard library skews what you end up doing. Perhaps. Well, contrasted to .Net and JVM standard libraries then? Ironically there is a plethora of ways to do the same thing in Python, but I guess the StackOverflow discussions tends to be about what the proper way is. So discussions about idiomatic Python is mostly cultural and not so much the language itself. There is also quite a bit of discussion about what is idiomatic D in these forums. So not all that different. Might be, I have used python hardly at all so can't be sure. C++ and Forth are examples of languages which share that philosophy of D. I don't see how Forth is comparable. Forth is essentially a minimalistic VM. So I think Lisp would be a better pairing for Forth. Both are at the other side of the spectrum of C++/D. In most regards they are very different, yes. But the similarity is that like C++/D, Forth is designed with many different programming styles in mind, instead of paving way primarily for one certain way of working. Probably Lisp too but I know too little of it to confirm. I don't think there is much of a clear philosophy behind D: C++ with GC, a slightly less verbose syntax, minus templating and some other things, then a bit of Java/C#, and finally a slightly different version of templating added. The standard library borrows conceptually from C++ and Python. How is the philosophy different from C++, except the GC which is a library feature in C++? The core language design and the production backend is essentially the same. D doesn't have enough libraries to distinguish itself culturally from the C-family either, so… Of course D is very close philosophically to C++, that's what gave it the name in the first place! The main difference is that there's no burden of backwards compatibilty with C/C++, and as proven it's enough of difference for many.
Re: What is the Philosophy of D?
On Wednesday, 18 October 2017 at 00:05:06 UTC, codephantom wrote: Again, philosophy != religion. Why do these terms get confused so much? I didn't mean they would be. I think that "D is not a religion" means that whatever philosophy it has it is not cast in stone. Not that it has no philosophy. Like you said, a certain kind of freedom is probably 1# in D philosophy but that does not mean it's the only part. Other thinkgs I could think of for example: -Let the programmer take charge, but make sure he's aware of it when doing so. -In "normal" code, first safety, then correctness, then performance, then expressiveness. Allow the user to shuffle this order but don't encourage it. -Don't strive for absolute minimalism, but aim for, in Alexandrescus words, "power-to-weight-ratio".
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: Is philosophy not important? I think that if somebody wants to nail down a philosophy for D, the main page puts it well: "The best paradigm is to not impose something at the expense of others". I also heard that long ago there was a phrase "D is not a religion". I wasn't myself here then but it still describes D alot. Well, I quess other phrases could also be included it, like "ultimate performance must be attainable, but if the way for it is otherwise undesirable it should be explicit" but the point is that D tries to let you to program in any style it technically can. With that "technically can" I mean that it does not support logic programming for example because it would require too great a rework on implementation and language spec. This is in contrast to Java and C# which almost force you to use object-oriented styles, and Python whose philosophy is "there should be one, and preferably only one clear way to do a thing". C++ and Forth are examples of languages which share that philosophy of D.
Re: Should we add `a * b` for vectors?
On Thursday, 5 October 2017 at 11:22:27 UTC, nkm1 wrote: It works, yes. The point is, additional methods in the struct body, and free standing functions outside of the body, but in the same module, is basically the same thing in D (I believe Andrei already mentioned that). But I meant extending the struct remotely from a different module. Ah, right. Well, anyway, that's not ADL by itself, since ADL only looks in the namespace of the argument type (so it won't find your extension methods if they're in some different namespace/module). Can well be, I don't know ADL precisely. Probably it should not be used as-is then, if at all.
Re: Should we add `a * b` for vectors?
On Thursday, 5 October 2017 at 10:07:31 UTC, nkm1 wrote:
Am I missing something? You can already extend the original
struct:
extern(c) struct Crng
{ int seedA;
int seedB;
ubyte[] restOfTheData;
extern (D) {
// or without extern (D)...
auto front() { return current(&this); }
void popFront() { toNextValue(&this); }
}
}
Does that work? If so, good. But still not optimal, because you
should be able to extend the functionality of code without
changing it.
Looks like what most people want are extension methods, not ADL?
We already have extension methods, but rather we want extension
methods that work with other extension methods they don't know
of. But I think that's what you meant and in this case the answer
at least in my case is yes.
Unrelated: Since when have C struct had array members? I'm not so
smart in my examples X).
Re: Should we add `a * b` for vectors?
On Thursday, 5 October 2017 at 09:39:58 UTC, Dukc wrote: On Thursday, 5 October 2017 at 09:26:44 UTC, Timon Gehr wrote: The "fix" is to add public import crng; to _std.range_. Yes, would work. I don't think it needs explanation why it's, as you said, more like a "fix" than a fix. Correction: Wouldn't quite do it, std.range would need to import the extension functions to crng, not it's C api. And it needn't to be a public import, if you also import it to it's child modules it happens to import. Otherwise correct.
Re: Should we add `a * b` for vectors?
On Thursday, 5 October 2017 at 09:26:44 UTC, Timon Gehr wrote: (That module is crng itself.) Depends on if he meant the extern (c) Crng or the range-implementing Crng. But would still not work, unless i have misunderstood something. The "fix" is to add public import crng; to _std.range_. Yes, would work. I don't think it needs explanation why it's, as you said, more like a "fix" than a fix.
Re: Should we add `a * b` for vectors?
On Thursday, 5 October 2017 at 08:27:14 UTC, Dukc wrote: and you have to rewrite many wrappers for Crng functions despite the alias this because they either require return Crng or gequire a pointer to one. Of course, If we could find a way to automate this universally, there would be much less if any need for ADL.
Re: Should we add `a * b` for vectors?
On Wednesday, 4 October 2017 at 17:56:16 UTC, Walter Bright wrote:
Please present an example.
Let's say you're importing a C library which defines random
function generators. They may be more random than Phobos rngs,
they might be crytpo secure or whatever so you want to use them.
It could be like:
module crng;
extern(c) struct Crng
{ int seedA;
int seedB;
ubyte[] restOfTheData;
}
extern(c) int current(Crng*);
extern(c) void toNextValue(Crng*);
extern(c) Crng initByTime(int unixTime);
//...
But you also want a phobos-style range interface for them. You
have to wrap the c struct into a new struct type:
struct Crng
{ crng.Crng _impl;
alias _impl this;
auto front(){return current(*_impl);}
void popFront(){toNextValue(*_impl);}
//...
}
and you have to rewrite many wrappers for Crng functions despite
the alias this because they either require return Crng or gequire
a pointer to one. This needs to be defined manually for example:
Crng initByTime(int time){return Crng(crng.initByTime(time))};
With ADL it would be enough to extend the original struct with
range primitives:
auto front(Crng range){return current(*range);}
void popFront(ref Crng range){toNextValue(*range);}
//...
With current semantics the latter example will work only with
locally defined range function templates. Not with Phobos ones,
because they cannot see the extension functions.
Note, I do not have a D compiler in where I posted these from so
they're not checked for compilation errors.
Re: Should we add `a * b` for vectors?
On Wednesday, 4 October 2017 at 17:56:16 UTC, Walter Bright wrote:
Please present an example.
Let's say you're importing a C library which defines random
function generators. They may be more random than Phobos rngs,
they might be crytpo secure or whatever so you want to use them.
It could be like:
module crng;
extern(c) struct Crng
{ int seedA;
int seedB;
ubyte[] restOfTheData;
}
extern(c) int current(Crng*);
extern(c) void toNextValue(Crng*);
extern(c) Crng initByTime(int unixTime);
//...
But you also want a probos-style range interface for them. You
have to wrap the c struct into a new struct type:
struct Crng
{ crng.Crng _impl;
alias _impl this;
auto front(){return current(*_impl);}
void popFront(){toNextValue(*_impl);}
//...
}
and you have to rewrite many wrappers for Crng functions despite
the alias this because they either require return Crng or gequire
a pointer to one. This needs to be defined manually for example:
Crng initByTime(int time){return Crng(crng.initByTime(time))};
With ADL it would be enough to extend the original struct with
range primitives:
auto front(Crng range){return current(*range);}
void popFront(ref Crng range){toNextValue(*range);}
//...
With current semantics the latter example will work only with
locally defined range function templates. Not with Phobos ones,
because they cannot see the extension functions.
Note, I do not have a D compiler in where I posted these from so
they're not checked for compilation errors.
Re: Should we add `a * b` for vectors?
On Tuesday, 3 October 2017 at 19:25:32 UTC, Walter Bright wrote: This is specifically designed to prevent nasty surprises. C++ has a big problem with ADL in that overloading is not encapsulated and any #included header can inadvertently add more overloads that may be entirely unrelated. Any .h can crack open any namespace and insert more overloads into it. It's completely unhygienic and uncontrollable. As for the specific example you gave, I get: a.d(3): Error: no property 'front' for type 'int[]' a.d(4): Error: no property 'save' for type 'int[]' b.d(8): Error: template instance a.sum!(int[]) error instantiating But you can't deny our solution eats expressive power: If you don't want to change code you're importing, you have to write a wrapper type for int[] here. Alias this helps, but because save() and slicing operators have to return the type of this, there's still manual work to do if you want Phobos algorithms to utilize it's random access. It may be that ADL or something similar would cause too much trouble to be worth it, don't know about that. But what I'm saying that we definitely have a considerable problem here and it would solve it.
Re: D's SwitchStatement accepts statements with ridiculous semantics
On Friday, 29 September 2017 at 09:12:54 UTC, Don Clugston wrote: Guess what this prints My guess is it prints "1". By "guess" I mean it, I did not test! Anyway reminds me a lot of very badly used gotos.
Re: Alternatives to pointers?
On Friday, 29 September 2017 at 01:51:36 UTC, Jerry wrote: Don't know how many times I've accidentially used a pointer as an array. Using @safe let's the compiler to catch that. Well, in it you can't use pointer arithmetic even explicitly, but if you have many elements to point at you're usually better off using a real array anyway.
Re: C `restrict` keyword in D
On Wednesday, 6 September 2017 at 17:30:44 UTC, Dukc wrote: See David Simcha's talk at DConf 13 at 37:30, that's the basic idea how I'm thinking the range would internally iterate. Correction: The outer loop would iterate in steps like that but the body would be different. It would each time copy elements into static array of length unroll.length (which in this case would be width of vector operations), let the user iterate over that and then assign it back to the original array.
Re: C `restrict` keyword in D
On Wednesday, 6 September 2017 at 09:21:59 UTC, Petar Kirov [ZombineDev] wrote: On Tuesday, 5 September 2017 at 15:46:13 UTC, Dukc wrote: [..] Of course, if we want to support this we should construct a high-level library template that chooses the correct vector size for the platform, eliminates that outer for loop and handles uneven array lenghts. You mean like this: https://github.com/dlang/druntime/pull/1891? No. I meant a function which, given an array, returns a range over that array which internally reads many elements at once from the array by copying them to a static array for handling. Then the compiler knows it can take advantage of optimizations like that pull request, because it knows static arrays can't overlap, even if the original arguments do. Of course the user should not call that function if the arrays do overlap, or if the loop body mutates other elements. See David Simcha's talk at DConf 13 at 37:30, that's the basic idea how I'm thinking the range would internally iterate. https://www.youtube.com/watch?v=yMNMV9JlkcQ&list=PLpISZoFBH1xtyA6uBsNyQH8P3lx92U64V&index=16
Re: Editor recommendations for new users.
On Sunday, 27 August 2017 at 10:28:29 UTC, Dukc wrote: I'm sure there are other good options too. The problem with geany is that it's syntax highlighting and auto-completion depend on having the file where the symbol's defined open. But that's because it's primarily a lightweight editor, not so much an IDE. It has some ide features, but I am not using them and don't know whether you can could solve these by creating a geny project. Also, like Lopatin said, DLangIDE is, at least theoretically a very good option. Despide being a real IDE, it is much smaller than Geany I meantioned, despite Geany being considered lightweight. And it's highlighting doesn't depend on files being opened fo editing. I have just started to use it, trough. Whether it's stable and polished enough to work well, I cannot tell yet.
Re: C `restrict` keyword in D
On Tuesday, 5 September 2017 at 18:32:34 UTC, Johan Engelen wrote:
My point was that that is not workable. The "null dereference"
is a D language construct, not something that the machine is
doing. It's ridiculous to specify that reading from address
1_000_000 should crash the program, yet that is exactly what is
specified by D when running this code (and thus null checks
need to be injected in many places to be spec compliant):
```
struct S {
ubyte[1_000_000] a;
int b;
}
void main() {
S* s = null;
s.b = 1;
}
```
-Johan
Perhaps it should nullcheck exceptionally large types which may
overflow the memory protected area, but not others?
Re: C `restrict` keyword in D
On Monday, 4 September 2017 at 18:03:51 UTC, Johan Engelen wrote:
It's need for auto-vectorization, for example.
I would support an LDC PR for adding a magic UDA to be able to
attach 'restrict' with C-semantics to function parameters. E.g.
```
// add restrict to parameters 1 and 2
void foo(int, int*, int*) @restrict(1,2)
```
That probably explains it in case of c. But I still think that D
might be able to do this better without language changes. This
way (not compiler-checked for errors):
```
for(int i = 0; i < a.length; i+=8)
{ int[8] aVec = a[i .. i+8], bVec = b[i .. i+8], cVec;
foreach(j; 0 .. 8) cVec[j] = aVec[j].foo(bVec[j]);
c[i .. i+8] = cVec[];
}
```
Of course, if we want to support this we should construct a
high-level library template that chooses the correct vector size
for the platform, eliminates that outer for loop and handles
uneven array lenghts.
Re: C `restrict` keyword in D
On Sunday, 3 September 2017 at 03:04:58 UTC, Uknown wrote: In C, the `restrict` keyword implies that 2 or more pointer arguments in a function call do not point to the same data. I really don't see where the restrict keyword is needed at all, neither in C nor in D. If you want to imply to the compiler that there is no need to reload the pointed data between uses, just assign it to a local.
Re: Editor recommendations for new users.
On Sunday, 27 August 2017 at 10:05:29 UTC, Nicholas Wilson wrote: So I will be doing a workshop on programming for the biology department at my university and I was wondering what would best suit the users. The following are a must: support windows & mac ( the more consistent between the two the better) free no large install footprint, preferably simple install procedure (running on laptops) syntax highlighting straightforward to use anything else is a bonus. Whats your experience with what you use? Many thanks Nic Those all apply to Geany. It's much like Notepad++ but crossplatform. I'm sure there are other good options too. The problem with geany is that it's syntax highlighting and auto-completion depend on having the file where the symbol's defined open. But that's because it's primarily a lightweight editor, not so much an IDE. It has some ide features, but I am not using them and don't know whether you can could solve these by creating a geny project.
Re: An Issue I Wish To Raise Awareness On
On Wednesday, 19 July 2017 at 15:38:08 UTC, Jack Stouffer wrote: Unless you're saying that the above should work even though it currently doesn't. Even then, I don't know about that. If your type is complex enough to need a shared dtor then the dtor probably needs to do some locking or extra checks. You don't want to impose that cost on a struct instance which isn't shared. Yes, just what I meant. And perfectly explained why we need something better.
Re: An Issue I Wish To Raise Awareness On
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov
[ZombineDev] wrote:
I think Atila was talking about this one:
struct A
{
~this() {}
}
void main()
{
auto a = A();
shared b = A();
}
Shouldn't it be :
struct A
{
~this() shared {}
}
void main()
{
auto a = A();
shared b = A();
}
?
Because handling theard-local data as shared is safe as far as I
remember, but not the other way round.
And if you want a destructor which works with both immutable and
normal, shouldn't it be a const destructor?
Re: If Statement with Declaration
On Wednesday, 19 July 2017 at 13:37:50 UTC, Adam D. Ruppe wrote: I like it. Me too. I think this should also apply to switch and with statements. Perhaps while statements too.
