Re: shared - i need it to be useful
Manu I'm also making a plea for you to write a document with your proposal which aggregates all relevant examples and objections. Then you can easily refer to it and we can introduce ppl to idea without reading a megathread.
Re: shared - i need it to be useful
On Thursday, 18 October 2018 at 20:07:54 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen wrote: On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov Manu said clearly that the receiving thread won't be able to read or write the pointer. Yes it will, by casting `shared` away. *Just like* his proposed "wrap everything into" struct will. There's exactly no difference. Casting is inherently unsafe. Or at least, there's no threadsafe guarantee. So? That's the only way to implement required low-level access, especially if we imagine that the part of Manu's proposal about disabling reads and writes on `shared` values is a given. It's the only way to implement Manu's Atomic!int, or at least operation it requires, for example. You can still disagree on the merits, but so far it has been demonstrated as a sound idea. No, it hasn't been. I think you are missing the wider point. I can write thread-unsafe code *right now*, no casts required. Just put shared at the declaration. The proposal would actually give some guarantees. No, I think you are missing the wider point. You can write thread-unsafe code regardless of using `shared`, and regardless of its implementation details. Allowing *implicit automatic promotion* of *mutable thread-local* data to shared will allow you to write even more thread-unsafe code, not less. This may come as a surprise but I agree with this factually. It's just that the extra guarantee provided by disallowing implicit casting to shared is not so valuable to me. If you have an object which can be used in both a thread-safe and a thread-unsafe way that's a bug or code smell. Like the earlier example with localInc() and sharedInc(). And we can't guarantee the safety of @trusted implementations anyways. If the extra guarantee is not valuable, might as well allow it. The solid part of the proposal is about disabling reads and writes. The rest is pure convention: write structs instead of functions, "Writing structs" seems acknowledging how it's usually done. And then you put these in a library with generic concurrent data structures. and somehow (???) benefit from a totally unsafe implicit cast. (See first part)
Re: Shared - Another Thread
Let me start by saying I'm willing to admit that I was factually wrong. Also keep in mind that "me having an impression" is something that is can't be independently verified and you'll have to take my at my word. Just that the exact reason for that impression was lost to the sands of time. On Thursday, 18 October 2018 at 20:13:49 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 20:10:18 UTC, Erik van Velzen wrote: When shared stood up in its current form, expectation was made "this will be threadsafe automatically - we'll figure out how in the future". It never was like that. At all. I don't think either Walter or Andrei are idiots, do you? Obviously not. But they are not infallible and can also change their mind. And features can be used beyond their initially envisioned purpose. Because it works for global variables. But it doesn't seem like an expectation we can deliver on. (I have no direct reference to this but that was certainly my impression) Your impression was wrong. Open e.g. TDPL and read up on `shared` how it was envisioned back then. I don't think the book really supports your argument. The first paragraph about shared sound to me like "the compiler will automagically fix it". Only tangentially it is mentioned that you're actually supposed to write special code yourself. You would have to be a compiler expert to draw the correct conclusion. Also the last paragraph the quote below is interesting in light of our other discussion about casting to shared. From the book: 13.11 The shared Type Qualifier (...) To the type system, shared indicates that several threads have access to a piece of data. The compiler acknowledges that reality by restricting operations on shared data and by generating special code for the accepted operations. (...) Because all shared data is accounted for and protected under the aegis of the language, passing shared data via send and receive is allowed. (...) 13.12 Operations with shared Data and Their Effects Working with shared data is peculiar because multiple threads may read and write it at any moment. Therefore, the compiler makes sure that all operations preserve integrity of data and also causality of operations. Reads and writes of shared values are allowed and guaranteed to be atomic: nu- meric types (save for real), pointers, arrays, function pointers, delegates, and class ref- erences. struct types containing exactly one of the mentioned types are also readable and writable atomically. (...) For all numeric types and function pointers, shared-qualified values are convertible implicitly to and from unqualified values. Pointer conversions between shared(T*) and shared(T)* are allowed in both directions. Primitives in std.concurrency allow you to do arithmetic on shared numeric types.
Re: Shared - Another Thread
On Thursday, 18 October 2018 at 19:09:42 UTC, Patrick Schluter wrote: On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: Elaborate on this... It's clearly over-ambitious if anything. What issues am I failing to address? I'm creating a situation where using shared has a meaning, is safe, and doesn't require any unsafe interactions, no casts, etc, for users at any level above the bare metal tooling... How would you improve on that proposition? No, your proposition is not the issue here. The problem I see is the expectation people have with what shared is supposed to do. I have the impression from reading in this forum about shared that people expect that just putting a shared in front of a variable will solve all the concurrency problems in existance. I think you hit the nail on the head here. When shared stood up in its current form, expectation was made "this will be threadsafe automatically - we'll figure out how in the future". Because it works for global variables. But it doesn't seem like an expectation we can deliver on. (I have no direct reference to this but that was certainly my impression) Your proposition doesn't want to address this utopic goal and that is a good thing imo. Adding that restriction that you propose makes explicit what was implied but not clearly stated until now. I'm not good enough in D to add more than a meta reflexion on the subject so I will not follow up on that. I often have the impression that a lot of things are going slower than necessary because a mentality where the perfect is in the way of good.
Re: shared - i need it to be useful
On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 19:04:58 UTC, Erik van Velzen wrote: On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov wrote: Doesn't work. No matter what you show Manu or Simen here they think it's just a bad contrived example. You can't sway them by the fact that the compiler currently *prevents* this from happening. Manu said clearly that the receiving thread won't be able to read or write the pointer. Yes it will, by casting `shared` away. *Just like* his proposed "wrap everything into" struct will. There's exactly no difference. Casting is inherently unsafe. Or at least, there's no threadsafe guarantee. Because int or int* does not have threadsafe member functions. int doesn't have any member functions. Or it can have as many as you like per UFCS. Same goes for structs. Because "methods" are just free functions in disguise, so that whole distinction in Manu's proposal is a weaksauce convention at best. You can still disagree on the merits, but so far it has been demonstrated as a sound idea. No, it hasn't been. I think you are missing the wider point. I can write thread-unsafe code *right now*, no casts required. Just put shared at the declaration. The proposal would actually give some guarantees.
Re: shared - i need it to be useful
On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote: On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote: Assuming the rules above: "can't read or write to members", and the understanding that `shared` methods are expected to have threadsafe implementations (because that's the whole point), what are the risks from allowing T* -> shared(T)* conversion? int i; tid.send(); ++i; // oops, data race Doesn't work. No matter what you show Manu or Simen here they think it's just a bad contrived example. You can't sway them by the fact that the compiler currently *prevents* this from happening. Manu said clearly that the receiving thread won't be able to read or write the pointer. Because int or int* does not have threadsafe member functions. You can still disagree on the merits, but so far it has been demonstrated as a sound idea.
Re: shared - i need it to be useful
I don't have anything to add that hasn't been said yet but it's good to see some thinking on this subject. It feels like progress.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 16:56:10 UTC, Neia Neutuladh wrote: On Saturday, 22 September 2018 at 16:56:10 UTC, Neia Neutuladh wrote: Walter was doing that thing that people in the US who only speak English tend to do: forgetting that other people speak other languages, and that people who speak English can learn other languages to work with people who don't speak English. He was saying it's inevitably a mistake to use non-ASCII characters in identifiers and that nobody does use them in practice. There's a more charitable view and that's that even furriners usually use English identifiers. Nobody in this thread so far has said they are programming in non-ASCII. If there was a contingent of Japanese or Chinese users doing that then surely they would speak up here or in Bugzilla to advocate for this feature?
Re: Updating D beyond Unicode 2.0
Agreed with Walter. I'm all on board with i18n but I see no need for non-ascii identifiers. Even identifiers with a non-latin origin are usually written in the latin script. As for real-world usage I've seen Cyrillic identifiers a few times in PHP.
Re: Using the result of a comma expression is deprecated
On Sunday, 27 November 2016 at 12:13:03 UTC, Nicholas Wilson
wrote:
On Sunday, 27 November 2016 at 11:49:25 UTC, Suliman wrote:
On Sunday, 27 November 2016 at 11:21:58 UTC, drug007 wrote:
void dbInsert(string login, string uploading_date, string
geometry_type, string data)
{
Statement stmt = conn.createStatement();
string sqlinsert = (`INSERT INTO usersshapes (userlogin,
uploading_date, geometry_type, data) VALUES ('%s', '%s', '%s',
'%s') `, login, uploading_date, geometry_type, data);
stmt.executeUpdate(sqlinsert);
scope(exit) stmt.close(); // closing
}
full code.
Looks like you forgot a call to format before the opening
parenthesis.
should be:
string sqlinsert = format(`INSERT INTO usersshapes (userlogin,
uploading_date, geometry_type, data) VALUES ('%s', '%s', '%s',
'%s') `, login, uploading_date, geometry_type, data);
because what ends up happening is :
string sqlinsert = data;
which is almost certainly not what you want.
As an aside, for security reasons you should use a prepared
statement.
Also, this is a decent usecase for scope(exit) but it should be
put earlier in the function.
Re: Is it possible to store different generic types in ex. an
On Wednesday, 9 November 2016 at 15:44:59 UTC, Is it possible to store different generic types? wrote: Foo[] foos; // Where Foo of course should allow any generic version of Foo You can use an array of std.variant
