Re: Create a List or Dictionary.
On Monday, 18 June 2018 at 13:23:37 UTC, Cym13 wrote:
Yes, this is what need, thank you very much for your help. :-)
On Monday, 18 June 2018 at 11:44:43 UTC, Sunny wrote:
[...]
If I read you well it seems the simplest equivalent code would
be:
struct MusicItem {
string URL;
string Artist;
string Title;
string Cover;
string Duration;
}
MusicItem[] musicList;
You could technically use tuples to get to the same point but I
don't really
see a point, structs fit that purpose very well.
Then you can:
musicList ~= MusicItem(url, artist, title, cover, duration);
musicList = [musicItem1, musicItem2];
or for dictionnaries:
MusicItem[string] musicDictionnary = [
"shortID1": MusicItem(foo, bar, baz, bak, biz, sub),
"shortID2": MusicItem(foo, bar, baz, bak, biz, sub),
];
etc.
[Issue 19003] format!"" breaks with structs containing invariants violated in .init
https://issues.dlang.org/show_bug.cgi?id=19003 --- Comment #1 from FeepingCreature --- PR is up: https://github.com/dlang/phobos/pull/6594 --
Re: UCFS does not work for nested functions?
On Monday, 18 June 2018 at 19:26:47 UTC, Steven Schveighoffer wrote: On 6/18/18 2:58 PM, aliak wrote: [...] It's the same in the fact that your call is silently switched to a different call. However, in the current syntax, an external entity CANNOT override a local function. When you call the nested function, it's the nested function, no matter what else occurs outside (even in the local module). There is no precedent for local functions to be overridden by module-level functions. [...] Ah I see. So it's basically that locals take priority, but if you allow them to UFCS then that's not true anymore because members need to take priority. Ok yep, that makes sense. Thanks !
Re: Cannot hash a std.datetime.Date
On Sunday, 17 June 2018 at 18:15:19 UTC, Per Nordlöw wrote:
The following
unittest
{
import std.datetime.date : Date;
Date date;
import core.internal.hash : hashOf;
auto hash = date.hashOf;
}
[...]
Well it definitely used to work before:
https://run.dlang.io/is/ayjpcH
I opened an issue for you:
https://issues.dlang.org/show_bug.cgi?id=19005
The PR that introduced this regression was
https://github.com/dlang/druntime/pull/2200
[Issue 19005] [REG2.081-b1] object.hashOf no longer works for std.datetime.date.Date
https://issues.dlang.org/show_bug.cgi?id=19005 --- Comment #1 from Seb --- Broken by https://github.com/dlang/druntime/pull/2200 --
[Issue 19005] New: [REG2.081-b1] object.hashOf no longer works for std.datetime.date.Date
https://issues.dlang.org/show_bug.cgi?id=19005
Issue ID: 19005
Summary: [REG2.081-b1] object.hashOf no longer works for
std.datetime.date.Date
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: greensunn...@gmail.com
void main()
{
import std.datetime.date : Date;
Date date;
auto hash = date.hashOf;
}
--
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Monday, 18 June 2018 at 06:54:46 UTC, Dukc wrote: 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. Yep, I'm aware of this and that's the argument why it has previously been rejected.
[Issue 18933] std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred)
https://issues.dlang.org/show_bug.cgi?id=18933 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9112e31e501c78e94470d3485484c580192da8fd Fix Issue 18933 - std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred) https://github.com/dlang/phobos/commit/653f382afe25852bf65ff0e73df30cac54c138f5 Merge pull request #6535 from n8sh/range-18933 Fix Issue 18933 - std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred) merged-on-behalf-of: Sebastian Wilzbach --
[Issue 18933] std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred)
https://issues.dlang.org/show_bug.cgi?id=18933 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18993] toLower is broken for UTF chars
https://issues.dlang.org/show_bug.cgi?id=18993 Seb changed: What|Removed |Added Status|NEW |RESOLVED CC||greensunn...@gmail.com Resolution|--- |FIXED --
[Issue 18804] std.algorithm.mutation.copy puts whole source range into target range when it should put elements
https://issues.dlang.org/show_bug.cgi?id=18804 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/19052b08de1e269bf7e8ad1fef89540a5427b5d7 fix issue 18804 - std.algorithm.mutation.copy puts whole source range into target range when it should put elements https://github.com/dlang/phobos/commit/1d70525d00ec2aa6dbbe2713531f6c9fc7e19abb Merge pull request #6485 from aG0aep6G/18804 fix issue 18804 - std.algorithm.mutation.copy puts whole source range… merged-on-behalf-of: Sebastian Wilzbach --
[Issue 18804] std.algorithm.mutation.copy puts whole source range into target range when it should put elements
https://issues.dlang.org/show_bug.cgi?id=18804 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: allMembers broke for __
On 6/18/18 5:27 PM, Walter Bright wrote: On 6/18/2018 3:54 AM, Timon Gehr wrote: The code you linked to does it. :) I know. But it shouldn't. Do as I say, not as I do :-) I don't see how you misuse the symbols. I think it's more that you shouldn't *define* these symbols, not that you can't use the language-defined symbols in the intended way. The complaint here is that they are treated differently from normal symbols. The answer is, they are special, so don't assume they aren't. -Steve
Re: UCFS does not work for nested functions?
On Monday, 18 June 2018 at 19:31:39 UTC, Steven Schveighoffer
wrote:
In other words, if UFCS meant that module-level symbols took
precedent over local symbols, then it's backwards in terms of
which place usually wins. Generally it's the local symbols.
Ah, you mean it would have to be that way to prevent breakage. No
I would not want it that way.
[...]
But one thing I will note, is that this is valid today:
void bar(int) {writeln("module");}
void main() {
static void bar(int) {writeln("local");}
int x;
x.bar; // "module"
}
Adding UFCS support to locals, which one would be the expected
call? It's difficult to imagine the local being the lower
priority, but it would have to be that way to avoid code
breakage.
Thanks, that clarifies it. No turtles for UFCS.
Re: allMembers broke for __
On 6/18/2018 3:54 AM, Timon Gehr wrote: The code you linked to does it. :) I know. But it shouldn't. Do as I say, not as I do :-)
[Issue 18782] Documentation error: ProtectionAttributes should say Visibility Attributes
https://issues.dlang.org/show_bug.cgi?id=18782 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/7c328266beac7f125bde5edc134d9fca9252e45d fix issue 18782 - Documentation error: ProtectionAttributes should say Visibility Attribute Also removing the outdated statement that visibility is not affected. Since DIP22, `private`, `public`, etc. do affect visibility. https://github.com/dlang/dlang.org/commit/78a09865cb0248edab239af41759948423ec3d90 Merge pull request #2350 from aG0aep6G/18782 fix issue 18782 - Documentation error: ProtectionAttributes should say Visibility Attribute --
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934 Walter Bright changed: What|Removed |Added Severity|normal |enhancement --- Comment #6 from Walter Bright --- New fix: https://github.com/dlang/dmd/pull/8369 done by adding 'scope' to struct declaration. --
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934 Walter Bright changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --
Re: Nothrow std.conv.to with explicit default value
On 6/18/18 4:48 PM, Per Nordlöw wrote: The problem with this code is that throwing exceptions for the default case is costly at least with dmd. Is there another way to do this? Yes, have an internal implementation which doesn't throw, but rather returns an error code. Then you can call that and throw or use default value based on the return value. It just means re-doing std.conv.to, which is pretty hairy, but also pretty well-organized. -Steve
Re: Nothrow std.conv.to with explicit default value
On Monday, 18 June 2018 at 20:48:55 UTC, Per Nordlöw wrote:
T toDefaulted(T, S, U)(S value, /*lazy*/ U defaultValue)
if (is(typeof(() { T r = defaultValue; }))) // TODO use
std.traits.isAssignable!(T, U) ?
why not just make it
T toDefaulted(T, S)(S value, T defaultValue)
and forget U entirely?
The problem with this code is that throwing exceptions for the
default case is costly at least with dmd. Is there another way
to do this?
It depends on what the types are. If it is like string to int,
you can simply scan the string for the appropriate format.
For other conversions though, I don't think you can tell in
general. User-defined types might not even tell you except by
exception.
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 08:39:07 UTC, Dmitry Olshansky wrote: On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D. T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes. async/await make asynchronous code in C# and JavaScript look clean and easy to wrap ones head around it. Solution to aka. callback hell. If popularity is what you're looking at, it JavaScript not Go. And async/await is all over the place...it more that a syntactic sugar, it a pattern. ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. Doesn't scales for what? Try C# or JavaScript and experience the true power of async/await.
Nothrow std.conv.to with explicit default value
I have a nothrow variant of std.conv.to defined as follows:
T toDefaulted(T, S, U)(S value, /*lazy*/ U defaultValue)
if (is(typeof(() { T r = defaultValue; }))) // TODO use
std.traits.isAssignable!(T, U) ?
{
try
{
import std.conv : to;
return value.to!T;
}
catch (Exception e) // assume `ConvException`. TODO can we
capture `ConvException` instead make it inferred `nothrow`
{
return defaultValue;
}
}
The problem with this code is that throwing exceptions for the
default case is costly at least with dmd. Is there another way to
do this?
[Issue 18996] Inserting a type containing indirections into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 --- Comment #8 from Paul Crane --- Thanks Steven for finding the bug and fixing it! It is appreciated! --
Re: emeralD - Command-line tool for template files
On Sunday, 17 June 2018 at 23:04:59 UTC, bauss wrote: emeralD is a command-line tool for template files that can be used to generate code files, configurations etc. It's a very useful tool for generating files that you'd normally have to create by hand. The idea for emeralD was not actually by me, but by Moogly (I don't know what he goes by in the forums, if he uses them.) who wanted something to generate files for ex. vibe.d and Diamond. Also additionally thanks to 0xEAB for a few ideas. emeralD is generic and not tied to D files only, but can be used for any type of file within any programming language. For more information see the Github repository and for examples see the read me. Github: https://github.com/DiamondMVC/emeralD Thank you! Sounds interesting. But the readme is missing a basic thing: a complete working example command for the impatient.
Re: What is the point of nothrow?
On Monday, June 18, 2018 15:22:48 wjoe via Digitalmars-d-learn wrote: > On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote: > > every feature that you can't use in betterC is considered a > > loss, and efforts are being made to make more of them work. > > There's always going to be a limit to that, and some D features > > just plain require druntime (just like some of C++'s features > > require a runtime), but it was never the point of betterC to > > strip out a bunch of D features. That's just the natural > > It is what it is and if what it is is the best tool to fix a > problem I would not hesitate to use it to that end. > > But you make it sound like betterC _should only_ work if actual D > code is called otherwise stick with good old C. From the POV of a > C programmer most of what betterC offers is a net gain and > nothing is a loss because what are they losing by upgrading from > C? And in general not paying for something you don't use or need > is considered a gain, no? I'm saying that -betterC is a subset of D that does not include D's runtime, and it includes as many of D's features as it currently can without using the runtime. You can choose to use it and never use normal D code, but the reason that it was created in the first place was so that it would be easier to port C code to D. Without -betterC, you tend to be forced to port the entire program at once, whereas with it, you can port it in pieces and then only switch to normal D once everything has been ported over. But there are some folks who elect to just write code targetting -betterC and who never intend for it to work as normal D code. > > consequence of the goal of being callable from C code without > > needing to worry about druntime. > > All of those features that betterC can't use can be avoided in > > normal D code if you don't want them for whatever reason. > > nothrow is actually one of the few cases where you have to > > explicitly do something in order to avoid that list of features > > that you have there. In the other cases, you just don't use the > > feature, and the only cost you're paying is the startup and > > shutdown time for druntime and the few resources that it uses. > > Please tell me. How would I disable just the Error mechanism, for > example ? > As far as I can tell it's not sufficient that I don't use nothrow > in my code because if it was used in phobos or druntime or some > other D code I'd have to deal with it. As with pretty much every other feature, if you don't want any Errors, you just don't use anything that uses it. The same goes with the GC and other features that you might choose to avoid. In some cases, that can be quite limiting, but it is possible to avoid it. It's simply that just like with any feature, avoiding it means losing out on features. The primary difference with nothrow over most other features is that the compiler inserts code by default for Exceptions if nothrow isn't there. So, using nothrow is required to turn that off, whereas for most other features, they only get used if you choose to use them (or use something that uses them). But it has nothing to do with Errors either way. The only way to avoid those is to never use a feature that could throw them (which can be done but would be so limiting that it's probably a waste of time). > But I know the answer to that. It's not possible because it was > never considered because why would anyone want to do that and > have the program just crash. > > Let's say I don't want to deal with OutOfMemoryError. That means > essentially I'm losing the GC. Which sucks big time as it is > _the_ selling point for me to use D over C. > > Let's say I didn't agree with RangeError for assoc. Arrays. I > imagine it allocates dynamically and hence has a dependency on > the GC so I have to consider the OutOfMemoryError headache even > if I would agree to RangeError. Solution again don't use it and > implement my own. > > Really, I don't see the difference between not using a feature > and not having a feature available; result's the same - I need a > solution/replacement. If having the program crash due to an error condition being considered fatal is unacceptable to you, then D will be unacceptable to you - including with -betterC, since in that case, the Errors get turned into failed C assertions that aren't compiled out. So, you won't get the stack unwinding, but your program will be purposefully killed either way, because it encountered an error condition that is considered fatal. You're free to disagree with that approach, and you're free to disagree with which error conditions are considered fatal, but it's part of using D. So, you'll either have to learn to live with that or use a different language. - Jonathan M Davis
Re: Aalborg D meetup
On Friday, 15 June 2018 at 08:45:29 UTC, Bienlein wrote: On Friday, 15 June 2018 at 07:34:07 UTC, biocyberman wrote: On Friday, 15 June 2018 at 07:20:04 UTC, Bienlein wrote: On Wednesday, 13 June 2018 at 12:37:26 UTC, bauss wrote: On Wednesday, 13 June 2018 at 12:12:11 UTC, bauss wrote: I'll be there since I live there and would be nice to see monthly meetups! :) I forgot to ask. Is it free entry? :) Yeah, and the Aalborg Akvavit is also free ? ;-) Depending on the volume you can take and how you transport to and from the meetup :) But I am taking some beer, soft drinks (saft vand?), fruit and chips. It's good for discussing socializing parts It is called soda vand, I think. Unhappily I'm about 1000 km away from Aalborg :-( I will explore further the possibility to make an online meetup after our first on-site one. If we do streaming on Youtube for example, everyone can join.
Re: D community's view on syntactic sugar
On Monday, 18 June 2018 at 01:06:48 UTC, evilrat wrote:
On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet
wrote:
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
He means that in D this is split like that, which isn't as
clean as C# does
class MyClass
{
private int _myProp; // backing field
private @property void myProp(int a) { _myProp = a; } //
private setter
public @property int myProp() { return _myProp; } // getter
}
Well the cool part about D is that we can generate such sugar
without necessarily needing to have it in the language (though a
better property syntax would be great).
Anyhow here's an example from the accessors package
(https://github.com/funkwerk/accessors):
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
// list all your fields here
mixin(GenerateFieldAccessors);
}
Re: UCFS does not work for nested functions?
On 6/18/18 2:57 PM, Bastiaan Veelo wrote:
On Monday, 18 June 2018 at 17:58:11 UTC, Steven Schveighoffer wrote:
On 6/18/18 1:25 PM, bauss wrote:
On Monday, 18 June 2018 at 17:16:29 UTC, aliak wrote:
On Monday, 18 June 2018 at 14:19:30 UTC, Steven Schveighoffer wrote:
On 6/18/18 7:16 AM, Bastiaan Veelo wrote:
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested functions,
and was wondering whether that's intended, and what the rationale
behind it is:
I just had the same question.
I can imagine that the context pointer of nested functions
complicates things, but making `bar` `static` does not help. Has
anything changed in recent years regarding the difficulty of
implementing UFCS for nested functions? Would it be easier to only
support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
It's never been supported, and likely will not be. I think the idea
is that you can override expected behavior inside by accidentally
defining some function locally with the same name.
Wondering how this is different than with non-nested functions? If a
global function has the same name as a member function then the
member function takes precedence. So wouldn't the same thing just
apply here if it were supported?
I second this.
What then can happen is that your local calls can get hijacked from
outside the module, if someone happens to define something later that
you happened to import. D tries to avoid such possibilities.
There's not much precedent for local symbols being overridden by
module-level symbols.
I don't understand. What local symbol would be overwritten by which
module-level symbol?
In other words, if UFCS meant that module-level symbols took precedent
over local symbols, then it's backwards in terms of which place usually
wins. Generally it's the local symbols.
Whatever the concerns, what is the difference regarding these concerns
between this:
```
// Valid today
void bar(int) {}
void main() {
int x;
b.bar;
}
```
and this:
```
\\ Invalid today
void main() {
static void bar(int) {}
int x;
x.bar;
}
```
It's a good question, I don't think it has a particularly satisfying
answer. But one thing I will note, is that this is valid today:
void bar(int) {writeln("module");}
void main() {
static void bar(int) {writeln("local");}
int x;
x.bar; // "module"
}
Adding UFCS support to locals, which one would be the expected call?
It's difficult to imagine the local being the lower priority, but it
would have to be that way to avoid code breakage.
-Steve
Re: UCFS does not work for nested functions?
On 6/18/18 2:58 PM, aliak wrote:
On Monday, 18 June 2018 at 17:58:11 UTC, Steven Schveighoffer wrote:
What then can happen is that your local calls can get hijacked from
outside the module, if someone happens to define something later that
you happened to import. D tries to avoid such possibilities.
There's not much precedent for local symbols being overridden by
module-level symbols.
I thought that happens already with non-nested functions:
module a;
struct A {
void f(); // assume it's added later
}
module b;
import a;
void f(A) { }
void g() {
auto x = A();
a.f(); // this would be calling local f until someone added A.f
}
Or I misunderstood what you said?
It's the same in the fact that your call is silently switched to a
different call. However, in the current syntax, an external entity
CANNOT override a local function. When you call the nested function,
it's the nested function, no matter what else occurs outside (even in
the local module). There is no precedent for local functions to be
overridden by module-level functions.
So if we allow this, we break a guarantee of which function is called,
albeit via a different syntax. Generally, the local function takes
precedence, then the member functions, then module-level functions.
Making the module level functions override the local functions is not
normal or expected. Generally you are defining locals to override what
you see outside the function.
But with UFCS, it's treated as part of the API of the type. The type
defines the API first, and then you can add to it, you can't override it.
Part of this is historical in nature -- UFCS came after member
functions, and so they had to be lower priority.
PS: This is something I've worried about before actually [1] when I was
more of a noob than now, but I've come to accept I guess :) though
I could still be misunderstanding things of course :/
https://forum.dlang.org/post/crcbaautgmrglhzvx...@forum.dlang.org
I think the current state of affairs still leaves some hijacking doors
open, depending on your point of view. It's certainly not perfect. The
only way to be sure you are doing things correctly is to use member
syntax when you know it's a member, and function syntax otherwise.
IMO, UFCS for locals isn't going to change, but I could also be wrong.
It's not really up to me what goes into the language, I just am trying
to help explain the rationale behind the current rules.
-Steve
Re: UCFS does not work for nested functions?
On Monday, 18 June 2018 at 17:58:11 UTC, Steven Schveighoffer
wrote:
What then can happen is that your local calls can get hijacked
from outside the module, if someone happens to define something
later that you happened to import. D tries to avoid such
possibilities.
There's not much precedent for local symbols being overridden
by module-level symbols.
-Steve
I thought that happens already with non-nested functions:
module a;
struct A {
void f(); // assume it's added later
}
module b;
import a;
void f(A) { }
void g() {
auto x = A();
a.f(); // this would be calling local f until someone added A.f
}
Or I misunderstood what you said?
Cheers,
- Ali
PS: This is something I've worried about before actually [1] when
I was more of a noob than now, but I've come to accept I guess :)
... though I could still be misunderstanding things of course :/
https://forum.dlang.org/post/crcbaautgmrglhzvx...@forum.dlang.org
Re: UCFS does not work for nested functions?
On Monday, 18 June 2018 at 17:58:11 UTC, Steven Schveighoffer
wrote:
On 6/18/18 1:25 PM, bauss wrote:
On Monday, 18 June 2018 at 17:16:29 UTC, aliak wrote:
On Monday, 18 June 2018 at 14:19:30 UTC, Steven Schveighoffer
wrote:
On 6/18/18 7:16 AM, Bastiaan Veelo wrote:
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested
functions, and was wondering whether that's intended, and
what the rationale behind it is:
I just had the same question.
I can imagine that the context pointer of nested functions
complicates things, but making `bar` `static` does not
help. Has anything changed in recent years regarding the
difficulty of implementing UFCS for nested functions? Would
it be easier to only support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
It's never been supported, and likely will not be. I think
the idea is that you can override expected behavior inside
by accidentally defining some function locally with the same
name.
Wondering how this is different than with non-nested
functions? If a global function has the same name as a member
function then the member function takes precedence. So
wouldn't the same thing just apply here if it were supported?
I second this.
What then can happen is that your local calls can get hijacked
from outside the module, if someone happens to define something
later that you happened to import. D tries to avoid such
possibilities.
There's not much precedent for local symbols being overridden
by module-level symbols.
-Steve
I don't understand. What local symbol would be overwritten by
which module-level symbol?
Whatever the concerns, what is the difference regarding these
concerns between this:
```
// Valid today
void bar(int) {}
void main() {
int x;
b.bar;
}
```
and this:
```
\\ Invalid today
void main() {
static void bar(int) {}
int x;
x.bar;
}
```
Re: how to determine of a module or any other symbol is visible?
On Monday, June 18, 2018 11:53:50 Cauterite via Digitalmars-d-learn wrote:
> On Monday, 18 June 2018 at 09:28:00 UTC, rikki cattermole wrote:
> > On 18/06/2018 9:24 PM, Mr.Bingo wrote:
> >> On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole
> >> wrote:
> >> This doesn't work with depreciation warnings.
> >
> > There won't be a way to check for those (I think).
> > Easier to not worry about them until it turns into errors.
>
> you can try the -de flag:
>
> // foo.d:
> deprecated void foo() {}
> pragma(msg, __traits(compiles, foo()));
>
> ---
>
> dmd foo.d
> -> true
>
> dmd -de foo.d
> -> false
>
> ---
>
> couldn't think of any examples of deprecated visibility to try
> though
Turning things into errors affects type introspection - e.g. the result on
__traits(comiles, ...) - so it's usually a bad idea. It's bad enough that -w
is a compiler flag without adding -de into the mix. That just makes it easy
to end up with code that doesn't compile or takes an unintended branch of a
static if, because a symbol was recently deprecated, and the code hasn't
been updated yet.
- Jonathan M Davis
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 --- Comment #15 from Jonathan M Davis --- (In reply to Nick Treleaven from comment #14) > This alone makes it an important feature. Actually, I think that it's caused more bugs than anything - especially when much is done with type introspection. Even though a property function tries to act like a variable, it isn't one and only marginally acts like one. Being able to call a function like a variable syntactically is useful, but semantically, it really isn't one, and having the symbol effectively lie about what it is makes writing good type introspection code harder (e.g. it made it harder to figure out a way to determine whether a member was a static variable or not when we originally tried to come up with how to implement hasStaticMember). As a systems language, it really isn't possible for a function to act completely like a variable, and having the function lie about it just because it's intended to partially emulate a variable does more harm than good IMHO - especially when it really has nothing to do with whether the function can be or is used with property syntax. > That would break much code significantly due to the above feature. AIUI > there is no way the current language can simulate that feature. > > I remind you again that this issue has nothing to do with optional > parenthesis. The point is that @property is considered a mistake by Walter and Andrei and is very much in limbo. What we have is a half-baked feature that does almost nothing and whose original design has clearly been abandoned. So, trying to "fix" it without there actually being an official decision about what we're going to do with it as a whole really doesn't make much sense - especially if that involves adding any compiler warnings or errors with regards to its use. --
Re: UCFS does not work for nested functions?
On 6/18/18 1:25 PM, bauss wrote:
On Monday, 18 June 2018 at 17:16:29 UTC, aliak wrote:
On Monday, 18 June 2018 at 14:19:30 UTC, Steven Schveighoffer wrote:
On 6/18/18 7:16 AM, Bastiaan Veelo wrote:
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested functions,
and was wondering whether that's intended, and what the rationale
behind it is:
I just had the same question.
I can imagine that the context pointer of nested functions
complicates things, but making `bar` `static` does not help. Has
anything changed in recent years regarding the difficulty of
implementing UFCS for nested functions? Would it be easier to only
support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
It's never been supported, and likely will not be. I think the idea
is that you can override expected behavior inside by accidentally
defining some function locally with the same name.
Wondering how this is different than with non-nested functions? If a
global function has the same name as a member function then the member
function takes precedence. So wouldn't the same thing just apply here
if it were supported?
I second this.
What then can happen is that your local calls can get hijacked from
outside the module, if someone happens to define something later that
you happened to import. D tries to avoid such possibilities.
There's not much precedent for local symbols being overridden by
module-level symbols.
-Steve
Re: UCFS does not work for nested functions?
On Monday, 18 June 2018 at 17:16:29 UTC, aliak wrote:
On Monday, 18 June 2018 at 14:19:30 UTC, Steven Schveighoffer
wrote:
On 6/18/18 7:16 AM, Bastiaan Veelo wrote:
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested
functions, and was wondering whether that's intended, and
what the rationale behind it is:
I just had the same question.
I can imagine that the context pointer of nested functions
complicates things, but making `bar` `static` does not help.
Has anything changed in recent years regarding the difficulty
of implementing UFCS for nested functions? Would it be easier
to only support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
It's never been supported, and likely will not be. I think the
idea is that you can override expected behavior inside by
accidentally defining some function locally with the same name.
-Steve
Wondering how this is different than with non-nested functions?
If a global function has the same name as a member function
then the member function takes precedence. So wouldn't the same
thing just apply here if it were supported?
Cheers,
- Ali
I second this.
Re: scope(success) lowered to try-catch ?
On Monday, 18 June 2018 at 12:48:46 UTC, Steven Schveighoffer wrote: On 6/17/18 11:58 PM, Neia Neutuladh wrote: [...] Yep, it's a good point. But also not the only way to do this. If you are returning void, just a goto would work: [...] I'm quite a noob when it comes to compiler stuff, and I see how this can be optimized when there're no exceptions, but I wonder what scope(success) actually means though without exceptions in play. It's just scope(exit) then right or? Cheers, - Ali
Re: UCFS does not work for nested functions?
On Monday, 18 June 2018 at 14:19:30 UTC, Steven Schveighoffer
wrote:
On 6/18/18 7:16 AM, Bastiaan Veelo wrote:
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested
functions, and was wondering whether that's intended, and
what the rationale behind it is:
I just had the same question.
I can imagine that the context pointer of nested functions
complicates things, but making `bar` `static` does not help.
Has anything changed in recent years regarding the difficulty
of implementing UFCS for nested functions? Would it be easier
to only support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
It's never been supported, and likely will not be. I think the
idea is that you can override expected behavior inside by
accidentally defining some function locally with the same name.
-Steve
Wondering how this is different than with non-nested functions?
If a global function has the same name as a member function then
the member function takes precedence. So wouldn't the same thing
just apply here if it were supported?
Cheers,
- Ali
Re: allMembers broke for __
On 6/18/18 12:57 PM, bauss wrote: On Monday, 18 June 2018 at 08:25:46 UTC, Russel Winder wrote: On Sun, 2018-06-17 at 15:55 -0700, Walter Bright via Digitalmars-d wrote: […] Identifiers starting with __ are reserved for the implementation: https://dlang.org/spec/lex.html#identifiers They have implementation-defined behavior. Do not use them in user code. In delegates I have found I have to use _ and __ (and ___, , etc.,but I have only had to use two to date) for delegate parameters that are to be unused and unnamed. Are these treated differently because they are all underscores? You can just not give them names. Well you can use identifiers that uses __, but certain names that uses __ as a prefix will have implementation defined behavior. I guess for parameters that are strictly __ etc. they're just behaving "normal" because there are no implementation behavior for said identifiers and thus defaults to "normal behavior". I also guess it's mostly an issue with function names, field names etc. and not really paramters, but I could be wrong. For names that won't be used, it doesn't matter what the name is. In some languages, the single underscore symbol is reserved for names that won't be used. So when porting to D, perhaps there is the case where you might feel they need other non-standard names. However, in this case, D does not require names, so it's a moot point. -Steve
Re: allMembers broke for __
On Monday, 18 June 2018 at 08:25:46 UTC, Russel Winder wrote: On Sun, 2018-06-17 at 15:55 -0700, Walter Bright via Digitalmars-d wrote: […] Identifiers starting with __ are reserved for the implementation: https://dlang.org/spec/lex.html#identifiers They have implementation-defined behavior. Do not use them in user code. In delegates I have found I have to use _ and __ (and ___, , etc.,but I have only had to use two to date) for delegate parameters that are to be unused and unnamed. Are these treated differently because they are all underscores? Well you can use identifiers that uses __, but certain names that uses __ as a prefix will have implementation defined behavior. I guess for parameters that are strictly __ etc. they're just behaving "normal" because there are no implementation behavior for said identifiers and thus defaults to "normal behavior". I also guess it's mostly an issue with function names, field names etc. and not really paramters, but I could be wrong.
[Issue 18996] Inserting a type containing indirections into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 Steven Schveighoffer changed: What|Removed |Added Summary|Inserting a struct into an |Inserting a type containing |std.container Array causes |indirections into an |SIGILL(4). Illegal |std.container Array causes |Instruction.|SIGILL(4). Illegal ||Instruction. --
Re: What is the point of nothrow?
On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote: On Saturday, June 16, 2018 18:45:53 wjoe via Digitalmars-d-learn wrote: What you said earlier: On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote: > [...] > > 2. If the compiler knows that a function can't throw an > Exception, then it doesn't have to insert any of the > Exception handling mechanism stuff [...] So, the fact that a > function is nothrow gives you a performance benefit, [...] > > - Jonathan M Davis made me believe that performance is one of the major reasons to use it. No? From the betterC page https://dlang.org/spec/betterc.html section 40.2: --- Not Available D features not available with BetterC: Garbage Collection TypeInfo and ModuleInfo Classes Built-in threading (e.g. core.thread) Dynamic arrays (though slices of static arrays work) and associative arrays Exceptions switch with strings final switch synchronized and core.sync Static module constructors or destructors Struct destructors unittest (testing can be done without the -betterC flag) --- Apart from a few convenience features lost this list reads like a shopping list for performance gain over full fledged D, in the spirit of nothrow omitting exception handling mechanism, to me. You gain from no garbage collection overhead, no vtable overhead, no RTTI overhead, no exception overhead, etc, etc, ... Back in the late 90ies I used to write the lion's share of code in Pascal and implement mission critical algorithms in asm. Worked back then why wouldn't it work today, except that I wouldn't use asm anymore but something like C or betterC. Thus, people who need this kind of performance boost can benefit 2 fold from using betterC. 1. They get to keep most of D's awesomeness, including compile time features, scope statements, RAII, lack of a pre processor, memory safety protections and complete meta programming, are just _some_ of the highlights. And on the other hand 2. they gain by getting rid of a lot the 'performance hogs' like GC, exceptions and more, right? And, with no exceptions altogether they do not need to worry about it at all. I'm sold! The _entire_ point of betterC is to be able to call D code from C code without having to deal with druntime (you can call D code from C code even without betterC, but then you have to worry about initializing and shutting down druntime). Basically BetterC sounds like a C language with tons of features from.. well actually...it sounds like a C language that fixes C's shortcomings. To get that point across it should maybe be called C2D Easy Interop Language. every feature that you can't use in betterC is considered a loss, and efforts are being made to make more of them work. There's always going to be a limit to that, and some D features just plain require druntime (just like some of C++'s features require a runtime), but it was never the point of betterC to strip out a bunch of D features. That's just the natural It is what it is and if what it is is the best tool to fix a problem I would not hesitate to use it to that end. But you make it sound like betterC _should only_ work if actual D code is called otherwise stick with good old C. From the POV of a C programmer most of what betterC offers is a net gain and nothing is a loss because what are they losing by upgrading from C? And in general not paying for something you don't use or need is considered a gain, no? consequence of the goal of being callable from C code without needing to worry about druntime. All of those features that betterC can't use can be avoided in normal D code if you don't want them for whatever reason. nothrow is actually one of the few cases where you have to explicitly do something in order to avoid that list of features that you have there. In the other cases, you just don't use the feature, and the only cost you're paying is the startup and shutdown time for druntime and the few resources that it uses. Please tell me. How would I disable just the Error mechanism, for example ? As far as I can tell it's not sufficient that I don't use nothrow in my code because if it was used in phobos or druntime or some other D code I'd have to deal with it. But I know the answer to that. It's not possible because it was never considered because why would anyone want to do that and have the program just crash. Let's say I don't want to deal with OutOfMemoryError. That means essentially I'm losing the GC. Which sucks big time as it is _the_ selling point for me to use D over C. Let's say I didn't agree with RangeError for assoc. Arrays. I imagine it allocates dynamically and hence has a dependency on the GC so I have to consider the OutOfMemoryError headache even if I would agree to RangeError. Solution again don't use it and implement my own. Really, I don't see the difference between not using a
[Issue 17656] Enum member circular reference error
https://issues.dlang.org/show_bug.cgi?id=17656 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- PR : https://github.com/dlang/dmd/pull/8371 --
[Issue 3567] std.traits: Unqual doesn't handle arrays well
https://issues.dlang.org/show_bug.cgi?id=3567 Steven Schveighoffer changed: What|Removed |Added Keywords||safe CC||schvei...@yahoo.com Hardware|Other |All OS|Linux |All Severity|normal |major --- Comment #4 from Steven Schveighoffer --- This is likely going to be disruptive to fix, so many things use Unqual. But nonetheless, it's an important bug. --
Re: UCFS does not work for nested functions?
On 6/18/18 7:16 AM, Bastiaan Veelo wrote:
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested functions, and
was wondering whether that's intended, and what the rationale behind
it is:
I just had the same question.
I can imagine that the context pointer of nested functions complicates
things, but making `bar` `static` does not help. Has anything changed in
recent years regarding the difficulty of implementing UFCS for nested
functions? Would it be easier to only support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
It's never been supported, and likely will not be. I think the idea is
that you can override expected behavior inside by accidentally defining
some function locally with the same name.
-Steve
Re: cyclic redundancy
On 6/18/18 4:45 AM, Mr.Bingo wrote:
I got tired of waiting for a solution and rolled my own:
static this()
{
import std.meta, std.stdio;
// Find all ___This functions linked to this module
auto Iterate()()
{
string[string] s;
void Iterate2(alias m, int depth = 0)()
{
static if (depth < 4)
{
static foreach (symbol_name; __traits(allMembers, m))
{
static if (symbol_name == "object") { }
else static if (symbol_name ==
m.stringof[7..$]~"___This")
{
s[m.stringof[7..$]] = m.stringof[7..$]~"___This";
} else static if (isModule!(__traits(getMember, m,
symbol_name)))
{
mixin("Iterate2!("~symbol_name~", depth +
1);");
}
}
}
}
mixin("Iterate2!("~.stringof[7..$]~");");
return s;
}
// Call all
enum fs = Iterate;
static foreach(k, f; fs)
mixin(k~"."~f~"();");
}
This code simply finds all ___This static functions linked to
the module this static constructor is called from and executes them.
This doesn't solve the original problem but lets one execute the static
functions to simulate static this. One could hypothetically even add
attributes to allow for ordering(which is what the original cyclic
redundancy check is suppose to solve but makes things worse since it is
an ignorant algorithm).
The algorithm in druntime is correct, I'm sure you mean that the data
provided to the algorithm is not detailed enough. This is actually a
very tricky thing to get right. What you may end up with is a program
that works or doesn't based on your linker order.
This type of method might be more feasible, a sort of static main(). It
does not check for static this of aggregates though but gets around the
CRC's banket fatal error.
The worst thing to consider is template class/struct static ctors which
get called in the *instantiating* module. I always recommend avoiding
putting those into your code.
-Steve
Re: cyclic redundancy
On 6/18/18 3:19 AM, Mr.Bingo wrote:
I have static this scattered throughout. Some are module static this and
some are struct and class.
In a test case I have reduced to a struct that uses a static this and I
get a cycle... even though, of course, the static this does nothing
accept internal things.
It is very annoying to have to hack these cycles. while they can be
bypassed for testing but production requires passing a runtime argument
which is useless for distribution to users.
The cyclic testing is so ignorant that it effectively makes using any
static this with any type of complex importing impossible, even though
no cycles actually exist.
Indeed, the module dependency information is very coarse, so it's very
easy to have "fake" cycles. All we look at is which modules import other
modules.
Note that the cycle detection and ordering is correct, given the limited
information the compiler provides.
Something new has to be done.
I propose that some way be made to disable a static this from being
included in the testing:
@NoCyclicRedundancyCheck static this()
{
}
I'd love to see something like this. Note that the cycle check is not
for redundancy, but for ordering how to call the static ctors. What you
really want to call this is @IndependentCtor or something like that.
This means that this segment of the static ctor does not depend on
anything initialized by other static ctors, and so can be called at any
time.
I'm not sure if attributes will persist at runtime though. Any method is
better than what we have now which essentially prevents all static this
usage because one can't guarantee that the future won't create a cycle
and then the program will break with no easy fix.
It would effectively split the static ctors into 2 functions, one that
can be called independently, and one that has to be sorted. How this is
normally handled is the compiler makes "fake" modules so it can put that
moduleinfo somewhere.
-Steve
[Issue 18996] Inserting a struct into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 Steven Schveighoffer changed: What|Removed |Added Keywords||pull CC||schvei...@yahoo.com Component|phobos |druntime Assignee|nob...@puremagic.com|schvei...@yahoo.com OS|Linux |All --- Comment #7 from Steven Schveighoffer --- The issue is that Array!string (or Array!T where T has indirections) is going to add its array as a range to the GC whenever it allocates one. What it does AFTER though is remove it's previous array as a range. When the Array has not been initialized yet, this is effectively calling GC.removeRange(null). The ProtoGC was asserting on that, generating the illegal instruction. However, the normal GC handled it just fine, which is why initializing the GC solved the problem. The ProtoGC should act exactly like the normal GC until the normal GC takes over, so this was a bug in the ProtoGC. PR: https://github.com/dlang/druntime/pull/2220 --
Re: What Is Python Developer Salary?
On Thursday, 12 April 2018 at 21:01:47 UTC, Arnold Blake wrote: I hired a remote developer in the language of the programming python, there was such a question as to how much should I pay him for the work? how many per hour? What kind of salary do they have, are different countries interested, Eastern Europe, India, etc? In the US alone it varies widely. Depends on region, demand, and cost of living. Out in Cali, your easily probably going to be expected to pay $100k+ for Python. On the east coast it can be that high as well in Boston, NY, or DC areas, but will go down depending on how far you get from the urban areas. Most software positions in the US pay salary (which is kind of BS, but it is the way it is). I have no clue about Europe or India.
Re: emeralD - Command-line tool for template files
On Monday, 18 June 2018 at 13:31:40 UTC, bauss wrote: The files will be created / copied to the current working directory. In the next version you'll be able to specify folders that you work in and give them a name which can be used to invoke emeralD from anywhere and still work in the directories you want.
Re: emeralD - Command-line tool for template files
On Monday, 18 June 2018 at 10:42:53 UTC, Dechcaudron wrote:
On Sunday, 17 June 2018 at 23:04:59 UTC, bauss wrote:
For more information see the Github repository and for
examples see the read me.
Could we get a complete, simple usage example? Like target
directory structure and how to invoke the program to get to it.
Simple template example for ex. a class:
```
emerald d class myclass myclass MyClass
...
emerald [root] [template] [$1] [$2] [$3]
```
Will generate a file called myclass.d with the following content:
```
module myclass;
class MyClass
{
public:
this()
{
}
}
```
An example on scaffolding ex. an empty project with a dub.json
would be:
```
-sc dub myproject -ex
```
Which will basically create a Hello World! example with a minimal
dub.json
It's possible to fetch scaffolding archives remote, as well fetch
templates online.
See the --remote / -r commands for that.
https://github.com/DiamondMVC/emeralD#--remote-root-template-url---rm-root-template-url
https://github.com/DiamondMVC/emeralD#--remote--scaffold-name-url---rm--sc-name-url
For examples on templates just see the the folders "templates"
and "scaffold" in the repository.
Re: What Is Python Developer Salary?
On Thursday, 12 April 2018 at 21:01:47 UTC, Arnold Blake wrote: I hired a remote developer in the language of the programming python, there was such a question as to how much should I pay him for the work? how many per hour? What kind of salary do they have, are different countries interested, Eastern Europe, India, etc? ython is a very widely used, general purpose, programming language. It is used to test chips, power apps, build games, automate tasks, and many other places. Its syntax allows programmers to express concepts in fewer lines of code than would be possible in languages such as C++ or Java. Average Trending Salary - $135k/year Below, you will find a short overview of the top 10 most expensive cities in the US and in Canada to hire a Python developer. Where applicable, I provide more detailed information on the salary levels for specific careers. If North America isn’t your thing, check out a similar ranking for Europe https://diceus.com/python-developer-salary/
Re: Create a List or Dictionary.
On Monday, 18 June 2018 at 11:44:43 UTC, Sunny wrote:
Hello, I'm having a problem, how can I create a List or
Dictionary in D?
In C #, I can create a tuple list, example:
var musicList = new List <(string URL, string Artist, string
Title, string Cover, string Duration)> ();
In Google did not find anything, tell me please how to get out
of this situation?
If I read you well it seems the simplest equivalent code would be:
struct MusicItem {
string URL;
string Artist;
string Title;
string Cover;
string Duration;
}
MusicItem[] musicList;
You could technically use tuples to get to the same point but I
don't really
see a point, structs fit that purpose very well.
Then you can:
musicList ~= MusicItem(url, artist, title, cover, duration);
musicList = [musicItem1, musicItem2];
or for dictionnaries:
MusicItem[string] musicDictionnary = [
"shortID1": MusicItem(foo, bar, baz, bak, biz, sub),
"shortID2": MusicItem(foo, bar, baz, bak, biz, sub),
];
etc.
[Issue 19004] Allow passing a string literal to an extern(C) variadic parameter
https://issues.dlang.org/show_bug.cgi?id=19004 Nick Treleaven changed: What|Removed |Added Keywords||pull URL||https://github.com/dlang/dm ||d/pull/8321 --
[Issue 19004] New: Allow passing a string literal to an extern(C) variadic parameter
https://issues.dlang.org/show_bug.cgi?id=19004
Issue ID: 19004
Summary: Allow passing a string literal to an extern(C)
variadic parameter
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: n...@geany.org
A string literal usually implicitly converts to a const(char)*. This is not
considered when passing one to an extern(C) variadic parameter - due to the
literal being interpreted as a slice, which is disallowed. The string should be
implicitly cast to a pointer, as string literals are always \0-terminated. This
is handy for C string compatibility, e.g. for formatting arguments:
dmd/toobj.d:
f.error("must be `extern(C)` for `pragma(%s)`",
isCtor ? "crt_constructor".ptr : "crt_destructor".ptr);
The `.ptr` property should not be necessary.
--
Re: scope(success) lowered to try-catch ?
On 6/17/18 11:58 PM, Neia Neutuladh wrote:
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
Is there a reason scope(success) needs to set up for exception handling?
Or is this a bug / potential enhancement ?
If you had no exception handling in place, you'd need to duplicate code
in the output. For instance:
void foo()
{
scope(success) writeln("success!");
if (a) return;
if (b) return;
throw new Exception;
}
This would have to be lowered to:
void foo()
{
if (a) { writeln("success!"); return; }
if (b) { writeln("success!"); return; }
throw new Exception;
writeln("success!"); // maybe omitted with flow analysis
}
Yep, it's a good point. But also not the only way to do this. If you are
returning void, just a goto would work:
void foo()
{
if(a) { goto L1; }
if(b) { goto L1; }
throw new Exception;
L1:
writeln("success1");
}
If you are returning a value, then you can establish a local variable
with the return value, and use a goto that way. It's already doing this
with "did it succeed", so adding another local variable is pretty trivial.
Bottom line is, the compiler understands flow control and can insert
structures like this without a huge impact.
I also think it's possible for the compiler to detect that a try/catch
clause is trivially omitted if we do it in the right way.
Now imagine there were 20 places you return from the function early. Now
imagine this is in a loop body, where you can leave it via goto, break,
continue, return, or end-of-block. And wrapped in several if statements.
These are all pretty easy to deal with. After all, they are essentially
glorified gotos.
You generate smaller code with the exception handling system. The
compiler only has to pay attention to scope guards in the code that
handles it directly, instead of at every flow control statement. Add to
that the fact that -betterC is pretty recent and scope guards are more
than ten years old, and you get this hole in the compiler.
I think the last point here is exactly why it was done this way -- the
original design of the compiler was to expect there were always
exception handling, so why not use it?
-Steve
[Issue 19003] New: format!"" breaks with structs containing invariants violated in .init
https://issues.dlang.org/show_bug.cgi?id=19003
Issue ID: 19003
Summary: format!"" breaks with structs containing invariants
violated in .init
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
Consider this code:
module test;
import std.conv : to;
import std.format : format;
struct S
{
int i;
@disable this();
this(int i) in { assert(i > 4); } body { this.i = i; }
invariant
{
assert(i > 4);
}
string toString() { return "S("~(i.to!string)~")"; }
}
void main() {
S s = S(5);
format!"s = %s"(s);
}
It's important to remember that Type.init is not necessarily a usable instance
of S. Most importantly, you cannot safely call methods on a T.init! That is not
what T.init is for.
Nevertheless, format!"" attempts to validate its format string by calling
format("s = %s", S.init) in CTFE. format then calls S.init.toString(), which
calls its invariant, which predictably errors.
Probably, just calling format with Args.init is not the right way to validate
the format string.
--
[Issue 19002] New: __FUNCTION__ and __PRETTY_FUNCTION__ are not C string literals
https://issues.dlang.org/show_bug.cgi?id=19002
Issue ID: 19002
Summary: __FUNCTION__ and __PRETTY_FUNCTION__ are not C string
literals
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid, wrong-code
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
void main()
{
import core.stdc.stdio;
printf(__FUNCTION__);
}
Error: function core.stdc.stdio.printf(scope const(char*) format, ...) is not
callable using argument types (string)
__FUNCTION__ should be equivalent to a string literal here. Using __FILE__ or
__MODULE__ works fine.
--
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 Nick Treleaven changed: What|Removed |Added Keywords||accepts-invalid --- Comment #14 from Nick Treleaven --- > 1. It affects the result of typeof (the result is the type of the return > value if @property is used, whereas it's the type of the function if > @property isn't used). This alone makes it an important feature. > The odds are very high that when Walter and Andrei finally get around to > deciding what to do with @property that they will simply decide to deprecate > it and remove it from the language That would break much code significantly due to the above feature. AIUI there is no way the current language can simulate that feature. I remind you again that this issue has nothing to do with optional parenthesis. --
Re: Create a List or Dictionary.
On 18/06/2018 11:44 PM, Sunny wrote: Hello, I'm having a problem, how can I create a List or Dictionary in D? In C #, I can create a tuple list, example: var musicList = new List <(string URL, string Artist, string Title, string Cover, string Duration)> (); In Google did not find anything, tell me please how to get out of this situation? https://dlang.org/spec/arrays.html#dynamic-arrays https://dlang.org/spec/hash-map.html
Re: how to determine of a module or any other symbol is visible?
On Monday, 18 June 2018 at 09:28:00 UTC, rikki cattermole wrote:
On 18/06/2018 9:24 PM, Mr.Bingo wrote:
On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole
wrote:
This doesn't work with depreciation warnings.
There won't be a way to check for those (I think).
Easier to not worry about them until it turns into errors.
you can try the -de flag:
// foo.d:
deprecated void foo() {}
pragma(msg, __traits(compiles, foo()));
---
dmd foo.d
-> true
dmd -de foo.d
-> false
---
couldn't think of any examples of deprecated visibility to try
though
Create a List or Dictionary.
Hello, I'm having a problem, how can I create a List or Dictionary in D? In C #, I can create a tuple list, example: var musicList = new List <(string URL, string Artist, string Title, string Cover, string Duration)> (); In Google did not find anything, tell me please how to get out of this situation?
Re: UCFS does not work for nested functions?
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested
functions, and was wondering whether that's intended, and what
the rationale behind it is:
I just had the same question.
I can imagine that the context pointer of nested functions
complicates things, but making `bar` `static` does not help. Has
anything changed in recent years regarding the difficulty of
implementing UFCS for nested functions? Would it be easier to
only support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
[Issue 19000] Building botan library causes segfault in dsymbolsem.d
https://issues.dlang.org/show_bug.cgi?id=19000 --- Comment #3 from Mike Franklin --- This bug report needs a dustmite reduction. It's easy to reproduce, but without a reduced test case to submit with the bug fix, this isn't going to get fixed any time soon. --
Re: allMembers broke for __
On 18.06.2018 00:55, Walter Bright wrote: On 6/15/2018 11:08 PM, DigitalDesigns wrote: When an identifier starts with __, allMembers does not return it. This is very bad behavior! It can silently create huge problems if the programmer is not aware of the bug. It's not a bug, it's quite deliberate: https://github.com/dlang/dmd/blob/master/src/dmd/traits.d#L1385 Identifiers starting with __ are reserved for the implementation: https://dlang.org/spec/lex.html#identifiers They have implementation-defined behavior. Do not use them in user code. The code you linked to does it. :)
Re: Compiler segfaults if not compiling with -debug #dbugfix
Can somebody explain what tnext does in TemplateInstance? It seems to be at the root of this stack overflow. The comment says it's "non-first instantiated instances", which is somewhat less than helpful.
[Issue 18026] Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()
https://issues.dlang.org/show_bug.cgi?id=18026
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #15 from FeepingCreature ---
Shorter repro:
module test;
struct FormatSpec() {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (is(T == string)) {
}
void formatValueImpl(W, T)(W w, T val, FormatSpec!() f)
if (is(T == int))
{
import std.range : iota;
static foreach (_; iota(1000))
{
formatValueImpl!(W, string)(w, "", f);
}
}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
alias fvi_Type_1 = formatValueImpl!(void function(char c), int);
alias fvi_Type_2 = formatValueImpl!(void function(const(char)[] s), int);
alias fvi_Type_3 = formatValueImpl!(void delegate(char c), int);
alias fvi_Type_4 = formatValueImpl!(void delegate(const char[]), int);
alias fvi_Type_5 = formatValueImpl!(void delegate(const(char)[] s), int);
void main() {}
Seems to happen more reliably in gdb. Since it's a stack overflow, recommended
to limit your stack size with ulimit -s 128 to test.
--
[Issue 18266] ICE: should allow reusing identifier in declarations in disjoint scopes in a function
https://issues.dlang.org/show_bug.cgi?id=18266 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- PR : https://github.com/dlang/dmd/pull/8370 --
[Issue 19000] Building botan library causes segfault in dsymbolsem.d
https://issues.dlang.org/show_bug.cgi?id=19000 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #2 from Mike Franklin --- Digger blames https://github.com/dlang/dmd/pull/6995 as the offending commit. --
Re: emeralD - Command-line tool for template files
On Sunday, 17 June 2018 at 23:04:59 UTC, bauss wrote: Github: https://github.com/DiamondMVC/emeralD Thank you! Scaffolding has now been added, along with shell command passing. This makes it possible to use emeralD for like project shells, build tool combination and multiple file generation.
Re: emeralD - Command-line tool for template files
On Sunday, 17 June 2018 at 23:04:59 UTC, bauss wrote: For more information see the Github repository and for examples see the read me. Could we get a complete, simple usage example? Like target directory structure and how to invoke the program to get to it.
Re: Help with DMD internals
On Monday, 18 June 2018 at 10:23:21 UTC, David Nadlinger wrote: On Monday, 18 June 2018 at 10:19:57 UTC, Nicholas Wilson wrote: You should get in contact with Manu Evans, he's working on this as well IIRC. Might be a lonely conversation – this is a spam-bot repost of one of Manu's messages. ;) —David No wonder it sounded like something Manu was doing.
Re: Help with DMD internals
On Monday, 18 June 2018 at 10:19:57 UTC, Nicholas Wilson wrote: You should get in contact with Manu Evans, he's working on this as well IIRC. Might be a lonely conversation – this is a spam-bot repost of one of Manu's messages. ;) —David
Re: Help with DMD internals
On Monday, 18 June 2018 at 09:58:05 UTC, kullboys wrote: Hello everyone Then... next up, extern(C++) classes need to place __xdtor in the vtable (posix uses 2 slots). We need the vtable to match naturally, without advising people to add a dummy method. I also have a hack in progress to support `final ~this()` in extern(C++) classes, which will omit it from the vtable (once it's in there!), since there are also C++ classes without virtual destructors. This work is hard... adding the dtor to the vtable freaks DMD out in all sorts of ways and ICE's everywhere. Any comments on any of these points appreciated. I don't know what I don't know. There's probably reasons that these things aren't all done already... Thanks[url=http://www.chevylegends.com/forum/showthread.php?1875-Introduction=12467].[/url] You should get in contact with Manu Evans, he's working on this as well IIRC.
Help with DMD internals
Hello everyone Then... next up, extern(C++) classes need to place __xdtor in the vtable (posix uses 2 slots). We need the vtable to match naturally, without advising people to add a dummy method. I also have a hack in progress to support `final ~this()` in extern(C++) classes, which will omit it from the vtable (once it's in there!), since there are also C++ classes without virtual destructors. This work is hard... adding the dtor to the vtable freaks DMD out in all sorts of ways and ICE's everywhere. Any comments on any of these points appreciated. I don't know what I don't know. There's probably reasons that these things aren't all done already... Thanks[url=http://www.chevylegends.com/forum/showthread.php?1875-Introduction=12467].[/url]
Re: how to determine of a module or any other symbol is visible?
On Monday, June 18, 2018 21:28:00 rikki cattermole via Digitalmars-d-learn wrote: > On 18/06/2018 9:24 PM, Mr.Bingo wrote: > > On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole wrote: > >> On 18/06/2018 9:03 PM, Mr.Bingo wrote: > >>> In the code I posted before about CRC, sometimes I get a visibility > >>> error for some modules. I would like to be able to filter those out > >>> using traits. Is there any way to determine if a module is > >>> visible/reachable in the current scope? > >>> > >>> The modules that are causing the problems are imported from other > >>> code that imports them privately. The iteration code still finds the > >>> module and tries to access it but this then gives a visibility > >>> error/warning. > >> > >> Quite often when working with CTFE, the easiest thing to do, is > >> to do a check to see if whatever you're doing compiles. Nice and > >> simple! > > > > This doesn't work with depreciation warnings. > > There won't be a way to check for those (I think). > Easier to not worry about them until it turns into errors. IIRC, there __traits(isDeprecated, symbol) should work now, though it's a recent addition. - Jonathan M Davis
Re: how to determine of a module or any other symbol is visible?
On 18/06/2018 9:24 PM, Mr.Bingo wrote: On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole wrote: On 18/06/2018 9:03 PM, Mr.Bingo wrote: In the code I posted before about CRC, sometimes I get a visibility error for some modules. I would like to be able to filter those out using traits. Is there any way to determine if a module is visible/reachable in the current scope? The modules that are causing the problems are imported from other code that imports them privately. The iteration code still finds the module and tries to access it but this then gives a visibility error/warning. Quite often when working with CTFE, the easiest thing to do, is to do a check to see if whatever you're doing compiles. Nice and simple! This doesn't work with depreciation warnings. There won't be a way to check for those (I think). Easier to not worry about them until it turns into errors.
Re: how to determine of a module or any other symbol is visible?
On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole wrote: On 18/06/2018 9:03 PM, Mr.Bingo wrote: In the code I posted before about CRC, sometimes I get a visibility error for some modules. I would like to be able to filter those out using traits. Is there any way to determine if a module is visible/reachable in the current scope? The modules that are causing the problems are imported from other code that imports them privately. The iteration code still finds the module and tries to access it but this then gives a visibility error/warning. Quite often when working with CTFE, the easiest thing to do, is to do a check to see if whatever you're doing compiles. Nice and simple! This doesn't work with depreciation warnings.
Re: how to determine of a module or any other symbol is visible?
On 18/06/2018 9:03 PM, Mr.Bingo wrote: In the code I posted before about CRC, sometimes I get a visibility error for some modules. I would like to be able to filter those out using traits. Is there any way to determine if a module is visible/reachable in the current scope? The modules that are causing the problems are imported from other code that imports them privately. The iteration code still finds the module and tries to access it but this then gives a visibility error/warning. Quite often when working with CTFE, the easiest thing to do, is to do a check to see if whatever you're doing compiles. Nice and simple!
how to determine of a module or any other symbol is visible?
In the code I posted before about CRC, sometimes I get a visibility error for some modules. I would like to be able to filter those out using traits. Is there any way to determine if a module is visible/reachable in the current scope? The modules that are causing the problems are imported from other code that imports them privately. The iteration code still finds the module and tries to access it but this then gives a visibility error/warning.
Re: cyclic redundancy
I got tired of waiting for a solution and rolled my own:
static this()
{
import std.meta, std.stdio;
// Find all ___This functions linked to this module
auto Iterate()()
{
string[string] s;
void Iterate2(alias m, int depth = 0)()
{
static if (depth < 4)
{
static foreach (symbol_name;
__traits(allMembers, m))
{
static if (symbol_name == "object") { }
else static if (symbol_name ==
m.stringof[7..$]~"___This")
{
s[m.stringof[7..$]] =
m.stringof[7..$]~"___This";
} else static if (isModule!(__traits(getMember, m,
symbol_name)))
{
mixin("Iterate2!("~symbol_name~", depth + 1);");
}
}
}
}
mixin("Iterate2!("~.stringof[7..$]~");");
return s;
}
// Call all
enum fs = Iterate;
static foreach(k, f; fs)
mixin(k~"."~f~"();");
}
This code simply finds all ___This static functions
linked to the module this static constructor is called from and
executes them.
This doesn't solve the original problem but lets one execute the
static functions to simulate static this. One could
hypothetically even add attributes to allow for ordering(which is
what the original cyclic redundancy check is suppose to solve but
makes things worse since it is an ignorant algorithm).
This type of method might be more feasible, a sort of static
main(). It does not check for static this of aggregates though
but gets around the CRC's banket fatal error.
Re: Friends in D, the easy way!
On Monday, 18 June 2018 at 06:37:41 UTC, Mr.Bingo wrote: These go in the module you want allow access to the outside world just as if they were in the same module! See the package attribute: https://dlang.org/spec/attribute.html#visibility_attributes
Re: Friends in D, the easy way!
On Monday, 18 June 2018 at 07:24:47 UTC, bauss wrote:
On Monday, 18 June 2018 at 06:37:41 UTC, Mr.Bingo wrote:
These go in the module you want allow access to the outside
world just as if they were in the same module!
auto Setter(string name, alias O, T)(T t)
{
mixin("t."~name~" = O();");
}
auto ref Getter(string name, T)(T t)
{
mixin("return t."~name~";");
}
x.Setter!("privateFieldName", { return value; }); //
privateFieldName = value;
x.Getter!("privateFieldName"); // = privateFieldName
You can think me now... or later, which ever you choose! I
hope there is no SOLID henchmen here!
Of course, these should be used only between modules that are
tightly coupled... This can happen when a derived class needs
access to it's parent as if it were in the same module but the
modules are split only for parsing.
Looks like it would be very verbose and honestly I'd rather see
an approach where the private fields has a public exposure
through a function or something.
It looks much cleaner IMO.
Doesn't matter, sometimes that just isn't the approach. Back in
the day I learned very quickly that if I had a star peg that it
wouldn't fit in the square hole so I found the star hole and
magically it worked like a charm! I learned from that day on that
it's not just the peg but also the hole! Fortunately I'm a fast
learner...
Re: Debugging silent exit of threads in Phobos calls
For anyone still interested in this problem: Steve's pull request fixing the problem is included in D 2.081.0. I can experiment as soon as DMD 2.081.0 is released but will have to wait till the fixes get into LDC to create production code. Moral of the story: silent, except during gdb debugging, assertion fails in Phobos are a pain in the arse. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: allMembers broke for __
On Sun, 2018-06-17 at 15:55 -0700, Walter Bright via Digitalmars-d wrote: > […] > Identifiers starting with __ are reserved for the implementation: > >https://dlang.org/spec/lex.html#identifiers > > They have implementation-defined behavior. Do not use them in user code. In delegates I have found I have to use _ and __ (and ___, , etc.,but I have only had to use two to date) for delegate parameters that are to be unused and unnamed. Are these treated differently because they are all underscores? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
[Issue 18996] Inserting a struct into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 --- Comment #6 from Paul Crane --- Thanks a lot for looking into this. Your fix does work for me as well. Thanks again it's much appreciated! --
Re: scope(success) lowered to try-catch ?
On Monday, 18 June 2018 at 03:58:47 UTC, Neia Neutuladh wrote:
...
yeah, at an AST level it makes sense why it was implemented like
this.
it's unfortunate that there's no straightforward way to express
'finally(success) {'.
Re: detectcycles: A source code dependency cycle checker
On Sunday, 17 June 2018 at 20:20:48 UTC, Mario Kröplin wrote: I did not mention it in the README, but the tred filter used in https://code.dlang.org/packages/depend complains about cyclic dependencies. I am currently working on a branch, where the transitive reduction and the corresponding warnings are built in. While this tool is for D only, it also allows to visualize and to check dependencies. Very nice project. The PlantUML output is a brilliant idea. In my case, I am mostly analyzing projects that are NOT in D, so I need a general purpose tool. I'm putting it through practical runs this morning and discovering areas of improvement. For example, in Java, one need not import dependencies within the same package, so I need to take a list of "uses" regex patterns instead of just having a single one, so that things like "@Autowired" from Spring can be detected as well.
[Issue 3567] std.traits: Unqual doesn't handle arrays well
https://issues.dlang.org/show_bug.cgi?id=3567
FeepingCreature changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||default_357-l...@yahoo.de
Resolution|INVALID |---
--- Comment #3 from FeepingCreature ---
This bug needs a second look.
Consider this code:
struct S
{
int* ipointer;
}
pragma(msg, (Unqual!(const S)).stringof);
As can be seen, Unqual has just deeply stripped const, not shallowly.
Either Unqual must be made to error when passed a const struct with reference,
or Unqual must leave const(int[]) as int[].
The current state is broken.
--
Re: Friends in D, the easy way!
On Monday, 18 June 2018 at 06:37:41 UTC, Mr.Bingo wrote:
These go in the module you want allow access to the outside
world just as if they were in the same module!
auto Setter(string name, alias O, T)(T t)
{
mixin("t."~name~" = O();");
}
auto ref Getter(string name, T)(T t)
{
mixin("return t."~name~";");
}
x.Setter!("privateFieldName", { return value; }); //
privateFieldName = value;
x.Getter!("privateFieldName"); // = privateFieldName
You can think me now... or later, which ever you choose! I hope
there is no SOLID henchmen here!
Of course, these should be used only between modules that are
tightly coupled... This can happen when a derived class needs
access to it's parent as if it were in the same module but the
modules are split only for parsing.
Looks like it would be very verbose and honestly I'd rather see
an approach where the private fields has a public exposure
through a function or something.
It looks much cleaner IMO.
[Issue 18984] Debugging stack struct's which are returned causes incorrect debuginfo.
https://issues.dlang.org/show_bug.cgi?id=18984 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #3 from Rainer Schuetze --- Might not be too complicated: https://github.com/dlang/dmd/pull/8368 --
cyclic redundancy
I have static this scattered throughout. Some are module static
this and some are struct and class.
In a test case I have reduced to a struct that uses a static this
and I get a cycle... even though, of course, the static this does
nothing accept internal things.
It is very annoying to have to hack these cycles. while they can
be bypassed for testing but production requires passing a runtime
argument which is useless for distribution to users.
The cyclic testing is so ignorant that it effectively makes using
any static this with any type of complex importing impossible,
even though no cycles actually exist.
Something new has to be done.
I propose that some way be made to disable a static this from
being included in the testing:
@NoCyclicRedundancyCheck static this()
{
}
I'm not sure if attributes will persist at runtime though. Any
method is better than what we have now which essentially prevents
all static this usage because one can't guarantee that the future
won't create a cycle and then the program will break with no easy
fix.
[Issue 18996] Inserting a struct into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 Basile B. changed: What|Removed |Added Component|druntime|phobos --- Comment #5 from Basile B. --- Problem is confirmed: Adding `gc_init()` in the Array `shared static this()` makes the problem going away. However for now `gc_init()` is private. One way to fix the issue is make `gc_init` public in druntime and add an explicit init call in `Array`. The other would be to make a dummy alloc if `Array` element has indirections. --
Re: IOS support status
On Sunday, 17 June 2018 at 01:50:14 UTC, Uknown wrote: On Saturday, 16 June 2018 at 12:59:48 UTC, makedgreatagain Darwin can generally imply either macOS, tvOS or iOS, as far as I can tell. Thanks for tips. @Joakim I speed the weekend on this and with no good results. abi-ios is not work with lts master anymore, because a lot code is changed.(not sure how to fix it) And after cherry pick ios-llvm tls patch to LLVM 37 or 60, none of them work. I try fix but not able to made it buildable. (base on ldc issue 1081, llvm no need tls patch if I understand correct) and make file also break so I has to remove the runtime folder to build ldc(not buildable because cpp error).
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.
Friends in D, the easy way!
These go in the module you want allow access to the outside world
just as if they were in the same module!
auto Setter(string name, alias O, T)(T t)
{
mixin("t."~name~" = O();");
}
auto ref Getter(string name, T)(T t)
{
mixin("return t."~name~";");
}
x.Setter!("privateFieldName", { return value; }); //
privateFieldName = value;
x.Getter!("privateFieldName"); // = privateFieldName
You can think me now... or later, which ever you choose! I hope
there is no SOLID henchmen here!
Of course, these should be used only between modules that are
tightly coupled... This can happen when a derived class needs
access to it's parent as if it were in the same module but the
modules are split only for parsing.
[Issue 19000] Building botan library causes segfault in dsymbolsem.d
https://issues.dlang.org/show_bug.cgi?id=19000 ag0aep6g changed: What|Removed |Added Keywords||ice CC||ag0ae...@gmail.com --
Re: iopipe v0.1.0 - now with Windows support!
On Sunday, 17 June 2018 at 04:52:07 UTC, Martin Nowak wrote: On 06/10/2018 10:10 PM, Steven Schveighoffer wrote: Note that the new io library also supports sockets, which IODev did not have support for, AND has a pluggable driver system, so you could potentially use fiber-based async io without rebuilding. It just makes a lot of sense for D to have a standard low-level io library that everything can use without having to kludge together multiple types of io libraries. Note that the WIP std.io library is fully @nogc @safe, so it's a bit edgy on using latest features. Soon want to move to use DIP10008 instead of preallocated exceptions. This is very encouraging. I’d like to see it working well with Photon (though my time is very limited atm). Any thoughts on what set of syscalls I need to support? Maybe I could just provide my own “native” driver that fits your concept of I/O driver in io library. With that and @nogc in the Driver interface¹ it's still to be seen whether we can adapt this well with vibe.d or need to adjust the low-level design. -Martin ¹: https://martinnowak.github.io/io/std/io/driver/Driver.html
Re: Cannot hash a std.datetime.Date
On Sunday, June 17, 2018 18:15:19 Per Nordlöw via Digitalmars-d wrote:
> The following
>
> unittest
> {
> import std.datetime.date : Date;
> Date date;
> import core.internal.hash : hashOf;
> auto hash = date.hashOf;
> }
>
> errors (with DMD v2.081.0-beta.1) as
>
> /usr/include/dmd/druntime/import/core/internal/convert.d(619,101): Error:
> template `core.internal.convert.toUbyte` cannot deduce function from
> argument types `!()(Month)`, candidates are:
> /usr/include/dmd/druntime/import/core/internal/convert.d(14,16):
> `core.internal.convert.toUbyte(T)(ref T val) if
> (is(Unqual!T == float) || is(Unqual!T == double) || is(Unqual!T
> == real) || is(Unqual!T == ifloat) || is(Unqual!T == idouble) ||
> is(Unqual!T == ireal))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(479,16):
> `core.internal.convert.toUbyte(T)(T[] arr) if (T.sizeof ==
> 1)`
> /usr/include/dmd/druntime/import/core/internal/convert.d(485,16):
> `core.internal.convert.toUbyte(T)(T[] arr) if
> (is(typeof(toUbyte(arr[0])) == const(ubyte)[]) && (T.sizeof > 1))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(503,16):
> `core.internal.convert.toUbyte(T)(ref T val) if
> (__traits(isIntegral, T) && !is(T == enum))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(537,16):
> `core.internal.convert.toUbyte(T)(ref T val) if
> (is(Unqual!T == cfloat) || is(Unqual!T == cdouble) || is(Unqual!T
> == creal))`
> /usr/include/dmd/druntime/import/core/internal/convert.d(619,101):
> ... (2 more, -v to show) ...
> /usr/include/dmd/druntime/import/core/internal/hash.d(145,37):
> Error: template instance `core.internal.convert.toUbyte!(Date)`
> error instantiating
> foo.d(6,21):instantiated from here: `hashOf!(Date)`
>
> but not with 2.080.1. A regression?
I'm not very familiar with the details of hashOf, so I can't say for sure
whether this is a regression or not, but in most cases, if something worked
in a previous release but doesn't work now, and there are no deprecation
messages involved, then it's probably a regression (especially if the
changelog doesn't say anything about it). Occasionally, the breakage is
intentional, but you pretty much can't go wrong by reporting it as a
regression. Worst case, it turns out that it was completely on purpose, and
the bug report will be closed accordingly. But if you don't report it as a
regression, and it is one, then it probably won't be fixed before the actual
release.
Glancing over the changelog, there are multiple entries which have to do
with improving core.internal.hash, and my guess would be that one of those
changes accidentally broke something.
- Jonathan M Davis
