Re: Error about constructor calls in loops/labels, but there are no loops and labels?
On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote: because it tends to become very difficult to get right in all cases and results in situations where the programmer is forced to do something in order to make the compiler shut up Well, doesn't this post show exactly this problem, and that's because the compiler is too dumb? Making the compiler smarter will only decrease the number of these cases.
Re: Sealed classes - would you want them in D? (v2)
On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote: On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote: But in D, everything is your friend - you don't get to manage You want to be taken seriously and yet you repeat false statements over and over again. There is absolutely no reason why D cannot have both (the current way D does it, and the C++ way). It's obviously technically possible. Being technically possible or even easy to implement is not an argument for including something. It's obvious it would attract a great deal more programmers to D. Pure conjecture. You don't know why people choose not to use D, you know why you choose not to use it. Assuming your opinion is shared by all these supposed people is at best naive at worst an indication of narcissism. I'll assume for now that you are young, idealistic and naive. It doesn't really complicate the language at all - that's just an excuse not to change. And, it's obvious, that protecting the interface would result in better quality software. It's a core fundamental principle of quality software. It's just a matter of getting more diverse people into the D 'community'. Yes because if a group of people don't accept your argument about something obviously there is something wrong with them. OK it's starting to look more like narcissism. But I get the feeling that's not what most D people want. The status quo is pretty comfortable for many, it seems. No shit... you're just getting that feeling now? You remind me of my teenage son, it takes about 100 times of telling him something before it sticks in his head. Let me ask you this... How do you get comfortable with something? By using it, trying it, and finding that it works. You don't get comfortable with having a stone in your shoe, so if this feature was the nightmare you say it is all these people using D wouldn't be OK with it. But again it's utterly pointless because you cannot grasp that. You are unable to even consider that something "other" might work. You are a zealot in that respect, that's why you exaggerate, misrepresent the other side of the argument, predict doom for the heathens, and never budge on your position. Anyway... feel free to misrepresent what I've said, engage in hyperbole, snip the parts you cant argue with, speak for all the people who chose not to use D, tell D it's doomed if they don't do what you say, it'll never be popular, that it's all idiotic. Etc...
Re: Error about constructor calls in loops/labels, but there are no loops and labels?
On Sunday, 20 May 2018 at 10:56:27 UTC, Yuxuan Shui wrote:
On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
because it tends to become very difficult to get right in all
cases and results in situations where the programmer is forced
to do something in order to make the compiler shut up
Well, doesn't this post show exactly this problem, and that's
because the compiler is too dumb?
Making the compiler smarter will only decrease the number of
these cases.
There is one construct which is guaranteed to run at the end...
this(ExceptionType t, long rowsNum, string file = __FILE__,
size_t line = __LINE__) pure @safe {
type = t;
string msg;
scope(exit) super(msg, file, line); // w00t
Re: auto: useful, annoying or bad practice?
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote: The return type for range-oriented functions in std.algorithm is usually not terribly useful. So the first question that comes to my mind are what are the 'rules' of the output. Which is really what typing is. It's a series of rules. Your object is allowed to call these methods/properties. It is 'this' size. Languages have generic returns. D is not the only language with a concept of returning a 'compiler determined type'. But the rules are always baked into the API. If it's not, it's a design failure and more thought should be put into it. The only place I wouldn't be so strict with auto returns is in private methods. However, I still might tell someone to think about what they are trying to return there. It's not an unimportant piece of the API.
Re: Error about constructor calls in loops/labels, but there are no loops and labels?
On Sunday, May 20, 2018 10:56:27 Yuxuan Shui via Digitalmars-d wrote: > On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote: > > because it tends to become very difficult to get right in all > > cases and results in situations where the programmer is forced > > to do something in order to make the compiler shut up > > Well, doesn't this post show exactly this problem, and that's > because the compiler is too dumb? > > Making the compiler smarter will only decrease the number of > these cases. Well, constructors are one of the few places that the compiler attempts flow analysis for stuff other than optimization, because it pretty much has to in order to do what the language needs. And no, it's not very sophisticated about it, because it's simpler to guarantee correctness that way. It also highlights why Walter is usually against doing much in the way of flow analysis. By designing the language such that it doesn't need much flow analysis, you mostly avoid problems like this. Unfortunately, it becomes more or less impossible to completely avoid it in constructors when you have const or immutable members, so the compiler does have to do some flow analysis in constructors. And it seems that Walter's solution in this sort of situation is to err on the side of having the compiler be stupid in order to avoid better guarantee correctness. Not being a compiler expert, I can't really comment on what the best approach would be here, but I know that Walter is typically against flow analysis at the semantic pass level precisely because it's very hard to get right, and it's always a battle between having it be sophisticated enough to not get in the programmers way and having it actually be guaranteed to be correct. As I understand it, flow analysis in stuff like the optimizer is _much_ easier, because the constructs you're dealing with are much easier. That's also why Walter and Andrei really like to design advanced language features in terms of lowering into simpler features (e.g. the use of destructors and scope statments all get lowered to try-catch-finally blocks). It's much easier to guarantee correctness with simpler features. As for this particular case, I expect that the best course of action is to report it in bugzilla and see what Walter thinks is the best approach. I can comment on Walter's basic approach and reasoning based on what he's said about these issues in the past, but I can't way what his response would be to this particular example. - Jonathan M Davis
Re: auto: useful, annoying or bad practice?
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote: D is very hard to make an IDE for that would actually tell you what type the return value is. This might sound a little hard, but that's probably a fundamental failure of the D language and explains some of the poor tooling around the language.
Re: Error about constructor calls in loops/labels, but there are no loops and labels?
On Sunday, 20 May 2018 at 14:39:28 UTC, Jonathan M Davis wrote: Well, constructors are one of the few places that the compiler attempts flow analysis for stuff other than optimization, because it pretty much has to in order to do what the language needs. And no, it's not very sophisticated about it, because it's simpler to guarantee correctness that way. It also highlights why Walter is usually against doing much in the way of flow analysis. By designing the language such that it doesn't need much flow analysis, you mostly avoid problems like this. Unfortunately, it becomes more or less impossible to completely avoid it in constructors when you have const or immutable members, so the compiler does have to do some flow analysis in constructors. And it seems that Walter's solution in this sort of situation is to err on the side of having the compiler be stupid in order to avoid better guarantee correctness. Not being a compiler expert, I can't really comment on what the best approach would be here, but I know that Walter is typically against flow analysis at the semantic pass level precisely because it's very hard to get right, and it's always a battle between having it be sophisticated enough to not get in the programmers way and having it actually be guaranteed to be correct. As I understand it, flow analysis in stuff like the optimizer is _much_ easier, because the constructs you're dealing with are much easier. That's also why Walter and Andrei really like to design advanced language features in terms of lowering into simpler features (e.g. the use of destructors and scope statments all get lowered to try-catch-finally blocks). It's much easier to guarantee correctness with simpler features. As for this particular case, I expect that the best course of action is to report it in bugzilla and see what Walter thinks is the best approach. I can comment on Walter's basic approach and reasoning based on what he's said about these issues in the past, but I can't way what his response would be to this particular example. - Jonathan M Davis I would argue that the best approach is to design the language to avoid flow analysis as much as possible. But for places that need it, the compiler should do as best as it can.
Re: auto: useful, annoying or bad practice?
On Sunday, May 20, 2018 14:33:16 I love Ice Cream via Digitalmars-d wrote: > On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote: > > The return type for range-oriented functions in std.algorithm > > is usually not terribly useful. > > So the first question that comes to my mind are what are the > 'rules' of the output. Which is really what typing is. It's a > series of rules. Your object is allowed to call these > methods/properties. It is 'this' size. Languages have generic > returns. D is not the only language with a concept of returning a > 'compiler determined type'. But the rules are always baked into > the API. If it's not, it's a design failure and more thought > should be put into it. > > The only place I wouldn't be so strict with auto returns is in > private methods. However, I still might tell someone to think > about what they are trying to return there. It's not an > unimportant piece of the API. That's where you get into a combination of needing good documentation and needing to know what set of traits to use to test the type to see what functionality it has. But for better or worse, asking a type what it can do is a key piece of Design by Introspection. The result can be extremely powerful, as Andrei has talked about on multiple occasions (I'd suggest watching his dconf 2015 talk about it if you haven't), but it does place a higher burden on the programmer to figure out how to use a type. So, there are pros and cons. Ultimately, auto can be extemely useful, and much of what we do with D really wouldn't be reasonably feasible without it, but it also needs to be used intelligently, because while it does bring some serious benefits, it can be at the cost of clarity if used poorly. - Jonathan M Davis
Re: Found on proggit: simple treap language benchmark, includes D
On Saturday, 19 May 2018 at 15:09:38 UTC, Joakim wrote: D does well, comes in second on Mac/Win/linux: https://github.com/frol/completely-unscientific-benchmarks https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/ The results in these tests are blazing fast, but they all forego the GC for manual allocation. In the Issues section of the repo, I included some simple, vanilla D translated from their Java implementation and made for use with the GC and runtime. I also included some raw sample times that are competitive with desktop i7 times of Rust and ref-counted C++ on...get this...a much slower laptop i5. This sort of thing needs to be shouted from the rooftops by the Foundation. I'll see if I can get it included so they can test it on their specific setup.
http://asm.dlang.org/ needs updating
load and save are not working, an example is always compiled in. No code in the input box still shows examples code in the disassembly.
Re: GDC Explorer - an online disassembler for D
On Friday, 21 September 2012 at 03:46:12 UTC, Andrei Alexandrescu
wrote:
I've met Matt Goldbolt, the author of the GCC Explorer at
http://gcc.godbolt.org - a very handy online disassembler for
GCC.
We got to talk a bit about D and he hacked together support for
D by using gdc. Take a look at http://d.godbolt.org, I think
it's pretty darn cool! I'm talking to him about integrating his
work with our servers.
Andrei
Compare a simple C++ to D and the C++ output is far better:
class C
{
int x = 12;
public:
int foo(int y) { return y*x; }
};
int main()
{
C* c = new C();
return c->foo(2);
}
VS
class C
{
int x = 12;
public:
int foo(int y) { return y*x; }
};
int main()
{
C c = new C();
return c.foo(2);
}
operator new(unsigned long)@plt:
jmpQWORD PTR [rip+0x200baa]# 601020 new(unsigned long)@GLIBCXX_3.4>
push 0x1
jmp400450 <.plt>
main:
push rbp
movrbp,rsp
push rbx
subrsp,0x18
movedi,0x4
call 400470
movrbx,rax
movDWORD PTR [rbx],0x0
movrdi,rbx
call 4005bc
movQWORD PTR [rbp-0x18],rbx
movrax,QWORD PTR [rbp-0x18]
movesi,0x2
movrdi,rax
call 4005a4
nop
addrsp,0x18
poprbx
poprbp
ret
nop
C::foo(int):
push rbp
movrbp,rsp
movQWORD PTR [rbp-0x8],rdi
movDWORD PTR [rbp-0xc],esi
movrax,QWORD PTR [rbp-0x8]
moveax,DWORD PTR [rax]
imul eax,DWORD PTR [rbp-0xc]
poprbp
ret
nop
C::C():
push rbp
movrbp,rsp
movQWORD PTR [rbp-0x8],rdi
movrax,QWORD PTR [rbp-0x8]
movDWORD PTR [rax],0xc
nop
poprbp
ret
nopWORD PTR cs:[rax+rax*1+0x0]
nopDWORD PTR [rax+rax*1+0x0]
VS
_Dmain:
push rbp
movrbp,rsp
subrsp,0x10
movrdi,QWORD PTR [rip+0x0]# f <_Dmain+0xf>
call 14 <_Dmain+0x14>
movQWORD PTR [rbp-0x8],rax
movesi,0x2
movrdi,rax
movrax,QWORD PTR [rax]
rex.W call QWORD PTR [rax+0x28]
leave
ret
addBYTE PTR [rax],al
main:
push rbp
movrbp,rsp
subrsp,0x10
movDWORD PTR [rbp-0x10],edi
movQWORD PTR [rbp-0x8],rsi
movrdx,QWORD PTR [rip+0x0]# 16
movrsi,QWORD PTR [rbp-0x8]
movedi,DWORD PTR [rbp-0x10]
call 22
leave
ret
.text.d_dso_init:
push rbp
movrbp,rsp
learax,[rip+0x0]# b <.text.d_dso_init+0xb>
push rax
learax,[rip+0x0]# 13 <.text.d_dso_init+0x13>
push rax
learax,[rip+0x0]# 1b <.text.d_dso_init+0x1b>
push rax
push 0x1
movrdi,rsp
call 26 <.text.d_dso_init+0x26>
leave
ret
the C++ version is more verbose, gives explicit references to
functions and methods while the D version requires you to hunt
and peck.
Re: auto: useful, annoying or bad practice?
On Sunday, 20 May 2018 at 14:35:21 UTC, I love Ice Cream wrote:
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
D is very hard to make an IDE for that would actually tell you
what type the return value is.
This might sound a little hard, but that's probably a
fundamental failure of the D language and explains some of the
poor tooling around the language.
This is specifically when metaprogramming is going on.
Most programming languages these days fall into one of three
categories:
* They don't support metaprogramming.
* They support metaprogramming by reflection only, like Java and
Go. As soon as you use any metaprogramming, your IDE can't tell
you what types things are; you've got interface{} or Object and
you're calling Field.get() and Method.invoke().
* They support metaprogramming by merit of being a dynamic
language. As soon as you write a line of code, your IDE can't
tell you what types things are.
If you write D without any metaprogramming, it's as easy to write
an IDE for that as for Java.
The problem is that metaprogramming is useful, and in D it's not
that hard, so we use it a lot. There are proposals floating
around for "concepts" or "signatures" (basically, compile-time
interfaces) that would help out a lot, but nobody's driven one of
those proposals to completion, as far as I know.
Re: http://asm.dlang.org/ needs updating
On 5/20/2018 9:47 AM, IntegratedDimensions wrote: load and save are not working, an example is always compiled in. No code in the input box still shows examples code in the disassembly. Please post bug reports to https://issues.dlang.org/
Help with DMD internals
I've started digging at some surfac-ey extern(C++) issues. First up, I desperately want a document that describes D's precise construction/destruction rules; there are a bunch of generated functions, they get called, in what order, and under what conditions? Construction: What is the order of operations? Where and when is init applied before calling constructors? What about super-constructors? Aggregate member constructors? When are where-from are they called? Is this all wrapped in an outer '__xctor' function that does the whole job? Is it all rolled into __ctor? Or is it just a bunch of loose operations that appear at the call-site? I want a function that wraps initialisation, super construction, aggregate construction, and local construction; similar to __xdtor is for destruction. That function would match C++, and that would be the logical point of interaction with C++ (mangling). Destruction: What's the precise story with __dtor, __xdtor, __fieldDtor? Is __xdtor **always** present? extern(C++) seems to have bugs(?) with __xdtor... Is re-initialisation to 'init' part of destruction, or is it a separate post-process? (I feel it's a post-process) Regarding extern(C++), I've started with trying to mangle correctly, but then next will come trying to match C++ semantics. Issue 1: extern(C++) classes have broken __xdtor. I observe extern(C++) classes with no destructor will generate an __xdtor that correctly calls aggregate destruction. If you then add a destructor (__dtor), __xdtor will call that function directly (or maybe it just becomes an alias?), and aggregate destruction will no longer occur. Issue 2: assuming the above is fixed, __xdtor matches C++ expectation for destruction. I intend to change the mangling such that __xdtor mangles as the C++ symbol, and not __dtor. Issue 3: If the user specifies an extern(C++) destructor *prototype* with no implementation (ie, extern link to C++ destructor), it needs a hack to re-interpret as a prototype for an extern __xdtor, rather than __dtor (and __dtor can happily not exist, or just alias). C++ destructors perform a full-destruction, which is equivalent to __xdtor from D's perspective. That should lead to destruction semantics matching C++. Matching construction semantics is a little bit fiddly too. It might need special-casing. D doesn't seem to wrap up a full construction into a single nice function like C++ does... or does it? I'm struggling to understand D construction from end-to-end. Let's not talk about passing by-val... yet.
Re: Help with DMD internals
On 20 May 2018 at 12:28, Manu wrote: > > [...] 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...
Re: Help with DMD internals
On 5/20/2018 12:28 PM, Manu wrote: I've started digging at some surfac-ey extern(C++) issues. I've improved the definition of how construction works, such as when the .init happens, in the spec. https://dlang.org/spec/class.html#constructors > Is __xdtor **always** present? No. If it's POD, it is not. When it is added, it is added as an AliasDeclaration, not a FuncDeclaration. See buildDtor() in clone.d, which is where it is created. You can also see in that function how _ArrayDtor and __fieldDtor are built on demand, and the order in which they are called.
Re: Help with DMD internals
On 5/20/2018 12:28 PM, Manu wrote: Is re-initialisation to 'init' part of destruction, No. or is it a separate post-process? (I feel it's a post-process) Yes, and only for delete.
A pattern I'd like to see more of - Parsing template parameter tuples
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
Something struck me at DConf. I was watching the dxml talk and
hearing about all these things that weren't being implemented for
one reason or another. And I was thinking, "But what if I want
those things?" Being D, it'd be pretty easy to opt in to them
with template parameters and static if controlling what code gets
executed at runtime.
But that brings up a bit of an annoying thing. Namely, the old
school way of doing such things:
class SomeObject( bool option1, bool option2, Flags iHateBools =
Flags.Default, int
ohIDontWantThisToBeDefaultedButRefactoringSucks = -1 )
{
}
Pretty obnoxious design pattern.
But we're in D. We can do much better. It makes sense to do the
following:
class SomeObject( LooseOptions... )
{
}
Much nicer. But how do we go about dealing with that? Static
foreach each time we want something? One time parse and cache the
values? Both are laborious in their own way. What we want is some
helper objects to make sense of it all.
This is where my EnumOptions struct comes in. The idea here is
that all the options you want as booleans, you put them in an
enum like so:
enum SomeOptions
{
Option1,
Option2,
Option5,
Option3Sir,
Option3
}
And then instantiate your class like so:
alias SomeInstantiatedObject = SomeObject!( SomeOptions.Option1,
SomeOptions.Option2, SomeOptions.Option3 );
And inside your class definition, you clean it up automagically
with a nice little helper function I made:
class SomeObject( LooseOptions... )
{
enum Options = OptionsOf( SomeOptions, LooseOptions );
}
This resolves to an EnumOptions struct that parses all members of
an enumeration, and generates bits in a bitfield for them and
wraps it all up with properties. So now the following is possible:
static if( Options.Option1 )
{
// Do the slow thing that I would like supported
}
Now, if you've been able to keep up here, you might have noticed
something. Your class has a variable template parameter list.
Which means we can throw anything in there. The plot thickens.
This means you can go one step further and make your options
actually human readable:
enum ObjectVersion
{
_1_0,
_1_1,
_2_0,
}
enum ObjectEncoding
{
UTF8,
UTF16,
UTF32,
PlainASCII,
ExtendedASCII,
}
class SomeDocument( Options... )
{
enum Version = OptionsOf( ObjectVersion, Options );
enum Encoding = OptionsOf( ObjectVersion, Options );
}
alias DocumentType = SomeDocument!( ObjectVersion._1_0,
ObjectEncoding.PlainASCII );
alias DocumentType2 = SomeDocument!( ObjectEncoding.UTF8,
ObjectVersion._2_0 );
Pretty, pretty, pretty good.
With this in the back of my mind, I've been able to expand
Binderoo's module binding to be a bit more user friendly. I've
got a new BindModules mixin, which unlike the existing mixins are
more of a pull-in system rather than a push-in system. Basically,
rather than BindModule at the bottom of each module, you put a
single BindModules at the bottom of one module and list every
module you want as a parameter to it.
The mixin needs to do a few things though. The list of modules is
one thing. A bunch of behaviour options is another. And, since
the mixin adds a static shared this, a list of functions that
need to be executed for module initialisation. The first two are
pretty easy to deal with:
enum Modules = ExtractAllOf!( string, Options );
enum BindOptions = OptionsOf!( BindOption, Options );
But the functions, they're a bit trickier. So I made a new trait
in Binderoo's traits module called ExtractTupleOf. The template
prototype is the following:
template ExtractTupleOf( alias TestTemplate, Symbols... )
That first parameter is the interesting one. It's essentially an
uninstantiated template that doubles as a lambda. The template is
expected to be an eponymous template aliasing to a boolean value,
and take one parameter (although, theoretically, a CTFE bool
function(T)() would also work). ExtractTupleOf will static
foreach over each symbol in Symbols, and static if(
TestTemplate!Symbol ) each one. If it returns true, then that
symbol is extracted and put in a new tuple.
What does this mean? It means I can do this:
import std.traits : isSomeFunction;
mixin BindModuleStaticSetup!( ExtractTupleOf!( isSomeFunction,
Options ) );
All of this is very definitely well in the real of "Let's see you
do that in the hour it took me to throw it all together, C++!"
territory. And I'd really like to see people pick up this pattern
rather than emulate the old ways.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
This looks good. One small caveat:
alias DocumentType = SomeDocument!(ObjectVersion._1_0,
ObjectEncoding.UTF8);
alias DocumentType2 = SomeDocument!(ObjectEncoding.UTF8,
ObjectVersion._1_0);
These are not the same type; they're two identical types with
different mangles. You can fix that with a layer of indirection:
template SomeDocument(Options...)
{
alias SomeDocument =
SomeDocumentImpl!(OptionsOf!(DocumentParams, Options));
}
Re: Help with DMD internals
On 20 May 2018 at 17:14, Walter Bright via Digitalmars-d wrote: > On 5/20/2018 12:28 PM, Manu wrote: >> >>Is re-initialisation to 'init' part of destruction, > > > No. > >> or is it a >> separate post-process? (I feel it's a post-process) > > > Yes, and only for delete. destroy() also seems to do it.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
I don't really like that SomeObject() will be instantiated a crap load
of times for every possible combination and order of options that a
user might want to supply. How do you control the bloat in a way that
people won't mess up frequently?
On 20 May 2018 at 17:58, Neia Neutuladh via Digitalmars-d
wrote:
> On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
>>
>> Code for context:
>> https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
>
>
> This looks good. One small caveat:
>
> alias DocumentType = SomeDocument!(ObjectVersion._1_0, ObjectEncoding.UTF8);
> alias DocumentType2 = SomeDocument!(ObjectEncoding.UTF8,
> ObjectVersion._1_0);
>
> These are not the same type; they're two identical types with different
> mangles. You can fix that with a layer of indirection:
>
> template SomeDocument(Options...)
> {
> alias SomeDocument = SomeDocumentImpl!(OptionsOf!(DocumentParams,
> Options));
> }
Re: auto: useful, annoying or bad practice?
auto has its uses, but it's wildly overused, especially in library code and documentation, and really, really, *really* much so in documentation examples. On 05/01/2018 06:09 AM, Craig Dillabaugh via Digitalmars-d wrote: On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote: I'll freely admit I haven't put a ton of thought into this post (never a good start), however I'm genuinely curious what people's feeling are with regards to the auto keyword. Speaking for myself, I dislike the auto keyword. Some of this is because I have a preference for static languages and I find auto adds ambiguity with little benefit. Additionally, I find it annoying that the phobos documentation relies heavily on auto obscuring return types and making it a bit more difficult to follow what is happening which gives me a bad taste for it. clip So I'm curious, what's the consensus on auto? As some have pointed out, it certainly has value. For example, in functions returning ranges, etc. where you wouldn't want to have to write out the whole type. However, as an infrequent D user I admit I prefer to see the actual type where it is feasible, as I find 'auto' is a barrier to understanding to someone who isn't familiar with a particular piece of code. I would never use auto in place of a basic type.
Re: Sealed classes - would you want them in D? (v2)
On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote: On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote: On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote: But in D, everything is your friend - you don't get to manage You want to be taken seriously and yet you repeat false statements over and over again. There is absolutely no reason why D cannot have both (the current way D does it, and the C++ way). It's obviously technically possible. Being technically possible or even easy to implement is not an argument for including something. It's obvious it would attract a great deal more programmers to D. Pure conjecture. You don't know why people choose not to use D, you know why you choose not to use it. Assuming your opinion is shared by all these supposed people is at best naive at worst an indication of narcissism. I'll assume for now that you are young, idealistic and naive. It doesn't really complicate the language at all - that's just an excuse not to change. And, it's obvious, that protecting the interface would result in better quality software. It's a core fundamental principle of quality software. It's just a matter of getting more diverse people into the D 'community'. Yes because if a group of people don't accept your argument about something obviously there is something wrong with them. OK it's starting to look more like narcissism. But I get the feeling that's not what most D people want. The status quo is pretty comfortable for many, it seems. No shit... you're just getting that feeling now? You remind me of my teenage son, it takes about 100 times of telling him something before it sticks in his head. Let me ask you this... How do you get comfortable with something? By using it, trying it, and finding that it works. You don't get comfortable with having a stone in your shoe, so if this feature was the nightmare you say it is all these people using D wouldn't be OK with it. But again it's utterly pointless because you cannot grasp that. You are unable to even consider that something "other" might work. You are a zealot in that respect, that's why you exaggerate, misrepresent the other side of the argument, predict doom for the heathens, and never budge on your position. Anyway... feel free to misrepresent what I've said, engage in hyperbole, snip the parts you cant argue with, speak for all the people who chose not to use D, tell D it's doomed if they don't do what you say, it'll never be popular, that it's all idiotic. Etc... Come on Dave. 18+ years, and still less than 1000 programmers. As I've said, I can have more that one class in a file in a variety of different mainstream languages, which represent about 20 million developers, and still have the compiler protect that interface from abuse, including accidental misuse. You cannot get this in D, and yet 20 million developers have had this for decades. When they come over to D, their' told, stuff you, we don't do it that way in D, and btw, we don't care about your ideas on how we could easily get D to do it both ways. We prefer our own way, so you get stuffed. That's kind of what I've hearing from the D community. Of course, that kind of attitude can only invite the same attitude back to the D community. Let's hope you truly don't represent the D community, cause then my comments are not hyperbole, they are fact.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote: But the functions, they're a bit trickier. So I made a new trait in Binderoo's traits module called ExtractTupleOf. The template prototype is the following: template ExtractTupleOf( alias TestTemplate, Symbols... ) That first parameter is the interesting one. It's essentially an uninstantiated template that doubles as a lambda. The template is expected to be an eponymous template aliasing to a boolean value, and take one parameter (although, theoretically, a CTFE bool function(T)() would also work). ExtractTupleOf will static foreach over each symbol in Symbols, and static if( TestTemplate!Symbol ) each one. If it returns true, then that symbol is extracted and put in a new tuple. Am I missing something, or is this the same thing as `std.meta: Filter`?
CI buildbots
This CI situation with the DMD/druntime repos is not okay. It takes ages... **hours** sometimes, for CI to complete. It's all this 'auto-tester' one, which seems to lock up on the last few tests. This makes DMD is a rather unenjoyable project to contribute to. I had a sudden burst of inspiration, but it's very rapidly wearing off.
Re: Sealed classes - would you want them in D? (v2)
On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote: I wouldn't consider putting classes into own modules a workaround. In my opinion it's more or less the solution. I'll add your solution into my article - but, I'm not sure it really addresses my problem statement. The Problem Statement (being drafted still): - In the D programming language, the semantics of the access-level modifier 'private' is likely very different to what a large number of programmers from object-oriented, and class-oriented languages, might expect. In D, the module (not the class) is the overarching entity, and one that encompasses all other entities within the module. In D, The module can contain (and typically would contain) a variety of types - functions, structs, classes and so on. If a module contains a class type however, and that class has a private access modifier on it's members, then that private access modifier becomes moot (within the module), because all the surrounding code in that module can directly access (and even modify) those private members. The module implicitly morphs a 'private' access modifier, into a 'private-but-also-module-public' modifier. The programmer has no control over this implicit conversion of the access modifier. This would be unfamiliar, and unexpected, to a very large number of programmers from languages where 'private' has an established and well-defined semantic as being the most restrictive form of access to a class member. Unfortunately, in the D programming language, there is simply no way to declare a member of a class to be private, and prevent surrounding code (within the module) from accessing it. The D module, will implicitly change the semantics of your code. The Implications: ..to do
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 01:53:20 UTC, Manu wrote: I don't really like that SomeObject() will be instantiated a crap load of times for every possible combination and order of options that a user might want to supply. How do you control the bloat in a way that people won't mess up frequently? Just sort types by .stringof in a thin forwarding template, we have sort in std.meta now. On 20 May 2018 at 17:58, Neia Neutuladh via Digitalmars-d wrote: [...]
