Re: What's C's biggest mistake?
On Friday, 25 December 2009 at 00:31:58 UTC, Walter Bright wrote: Andrei and I were just talking about programming language books, and how we both thought it was disingenuous that some of them never admit to any flaws in the language. We hope we don't fall into that trap. Whoops.
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/2012 10:32 PM, Nick Sabalausky wrote: On Wed, 07 Nov 2012 14:40:33 -0800 Walter Bright wrote: Of course we all take it for granted that Basic sux and does everything wrong, Which Basic? ;) (<-- Just as one example) All of them!
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wed, 07 Nov 2012 14:40:33 -0800 Walter Bright wrote: > > Of course we all take it for granted that Basic sux and does > everything wrong, Which Basic? ;) (<-- Just as one example)
Re: [ ArgumentList ] vs. @( ArgumentList )
Am Wed, 07 Nov 2012 16:19:56 +0100 schrieb Jacob Carlborg : > On 2012-11-07 14:40, deadalnix wrote: > > > I think D has already too many feature, and that many of them can be > > implemented as attribute + AST processing. > > > > D should work toward getting this AST stuff and stop adding new keywords > > all the time. > > I completely agree. Which features are that? It would likely require a major rewrite of many routines. Who would want to go through all that and the following wave of bugs - some of which may have already occurred in the past. foreach and scope(...) lowerings are essentially AST operations. Are there other D features you would implement as AST processing, maybe a link to an earlier post ? How close is Rust currently to offering flexible AST manipulation for lowerings/attributes/macros, does anyone know ? -- Marco
Re: Const ref and rvalues again...
On Thursday, October 18, 2012 05:07:52 Malte Skarupke wrote: > What do you think? Okay. Here are more links to Andrei discussing the problem: http://forum.dlang.org/post/4f83dbe5.20...@erdani.com http://www.mail-archive.com/digitalmars-d@puremagic.com/msg44070.html http://www.mail-archive.com/digitalmars-d@puremagic.com/msg43769.html http://forum.dlang.org/post/hg62rq$2c2n$1...@digitalmars.com He is completely convinced that letting rvalues bind to const& in C++ was a huge mistake, and it seems to come down mainly to this: "The problem with binding rvalues to const ref is that once that is in place you have no way to distinguish an rvalue from a const ref on the callee site." And apparenly it required adding the concept of rvalue references to C++, which complicated things considerably. It's too bad that he hasn't replied to some of the more detailed questions on the matter in this thread, but if you want rvalues to bind to const ref in D, you're going to have to convince him. At this point, I expect that the most likely solution is that auto ref will continue to work like it does in templates but for non-templated functions it will become like const ref is in C++ and accept rvalues without copying lvalues. Andrei suggests that in at least one of those posts, and AFAIK, it would work just fine. The only real downside that I'm aware of is that then the semantics of auto ref are slightly different for non-templated functions, but you're doing basically the same thing with auto ref in both cases - avoiding copying lvalues and only copying rvalues when you have to - so it really shouldn't be a problem. The main problem is that someone needs to go and implement it. - Jonathan M Davis
Re: Const ref and rvalues again...
On Wednesday, 7 November 2012 at 21:39:52 UTC, Timon Gehr wrote: You can pass him an object that does not support operations you want to preclude. He does not have to _know_, that your book is not changed when he reads it. This is an implementation detail. In fact, you could make the book save away his reading schedule without him noticing. I don't see where you want to go with this. Do you suggest creating tailored objects (book variants) for each function you're gonna pass it to just to satisfy perfect theoretical encapsulation? So foo() shouldn't be able to change the author => change from inout author reference to const reference? bar() should only be allowed to read the book title, not the actual book contents => hide that string? ;) For the sake of simplicity, by using const we have the ability to at least control if the object can be modified or not. So although my colleague doesn't have to _know_ that he can't modify my book in any way (or know that the book is modifiable in the first place), using const is a primitive but practical way for me to prevent him from doing so. In the context of this rvalue => (const) ref discussion, const is useful due to a number of reasons. 1) All possible side effects of the function invokation are required to be directly visible by the caller. Some people may find that annoying, but I find it useful, and there's a single-line workaround (lvalue declaration) for the (in my opinion very rare) cases where a potential side-effect is either known not to occur or simply uninteresting (requiring exact knowledge about the function implementation, always, i.e., during the whole life-time of that code!). 2) Say we pass a literal string (rvalue) to a const ref parameter. The location of the string in memory can then be freely chosen by the compiler, possibly in a static data segment of the binary (literal optimization - only one location for multiple occurrences). If the parameter was a mutable ref, the compiler should probably allocate a copy on the stack before calling the function, otherwise the literal may not be the same when accessed later on, potentially causing funny bugs. 3) Implicit type conversion isn't a problem. Say we pass an int rvalue to a mutable double ref parameter. The parameter will then be a reference to another rvalue (the int cast to a double) and altering it (the hidden double rvalue) may not really be what the coder intended. Afaik D doesn't support implicit casting for user-defined types, so that may not be a problem (for now at least).
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/2012 4:03 PM, Andrei Alexandrescu wrote:
On 11/7/12 10:24 PM, Walter Bright wrote:
On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
I we were to allow for @foobar style UDA then "safe" would have to be
a reserved
keyword somehow. Otherwise I do not know what this would mean:
struct safe { }
@safe void foobar() { }
Yes, I agree this is a significant problem.
I think it's solvable. The basic approach would be to plop types "safe",
"nothrow" etc. in object.di and then let them just behave like all other
arguments.
Consider that if we do that, then someone will need to disambiguate with:
@object.safe
which is ambiguous:
@a.b .c x = 3;
or is it:
@a .b.c x = 3;
?
Another problem is it pushes off recognition of @safe from the parser to the
semantic analyzer. This has unknown forward reference complications.
Re: UDAs - Restrict to User Defined Types?
On 11/08/2012 12:18 AM, Walter Bright wrote: Started a new thread on this. On 11/7/2012 3:05 AM, Leandro Lucarella wrote: > OK, that's another thing. And maybe a reason for listening to people having > more experience with UDAs than you. > > For me the analogy with Exceptions is pretty good. The issues an conveniences > of throwing anything or annotating a symbol with anything instead of just > type are pretty much the same. I only see functions making sense to be accepted > as annotations too (that's what Python do with annotations, @annotation symbol > is the same as symbol = annotation(symbol), but is quite a different language). There's another aspect to this. D's UDAs are a purely compile time system, attaching arbitrary metadata to specific symbols. The other UDA systems I'm aware of appear to be runtime systems. This implies the use cases will be different - how, I don't really know. But I don't know of any other compile time UDA system. Experience with runtime systems may not be as applicable. Another interesting data point is CTFE. C++11 has CTFE, but it was deliberately crippled and burdened with "constexpr". From what I read, this was out of fear that it would turn out to be an overused and overabused feature. Of course, this turned out to be a large error. One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say "I want to look in module X for symbols." Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? It's not quite analogous to exceptions, because arbitrary exceptions thrown from module X can flow through your code even though you have no idea module X even exists. This is a valid point, and I think it does not really make sense to only exclude built-in types. Any type not intended for use as an attribute and that is exported to sufficiently many places can have the same behaviour. I'd vote no restrictions at all, or for requiring @attribute annotations on the user-defined type and ban user-defined types from being annotations that do not have that.
Re: Mediawiki vs. Gollum vs ...
On Wednesday, 7 November 2012 at 16:01:52 UTC, Thomas Koch wrote: The only show stopper of Mediawiki would be, if there was nobody to host and maintain it for D. Can you recommend a Mediawiki hosting service? This is a fair question I unfortunately don't have a good answer for. However, I was hoping that we could make the wiki "more official" by moving it to http://wiki.dlang.org anyway, so we might have a similar problem when e.g. going for Gollum. David
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/8/12, David Nadlinger wrote: > On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu > wrote: > "nothrow" isn't actually an @attribute. So much for the value of > consistency… :o) Another classic inconsistency: @disable and deprecated Not only that but I keep writing the former as @disabled and get CT errors.
Re: What's C's biggest mistake?
On Wednesday, 7 November 2012 at 21:36:57 UTC, Ali Çehreli wrote: On Thursday, 24 December 2009 at 19:52:00 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/ai9uc/whats_cs_biggest_mistake/ That article is not on Dr.Dobb's anymore: http://www.drdobbs.com/author/Walter-Bright Is there a copy somewhere else? Ali I think I've seen that with other articles. Dr. Dobb's does not appear to provide very permanent hosting for articles.
Re: [ ArgumentList ] vs. @( ArgumentList )
On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu wrote: I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments. "nothrow" isn't actually an @attribute. So much for the value of consistency… :o) David
Re: UDAs - Restrict to User Defined Types?
On 2012-11-08, 00:18, Walter Bright wrote: Started a new thread on this. On 11/7/2012 3:05 AM, Leandro Lucarella wrote: > OK, that's another thing. And maybe a reason for listening to people having > more experience with UDAs than you. > > For me the analogy with Exceptions is pretty good. The issues an conveniences > of throwing anything or annotating a symbol with anything instead of just > type are pretty much the same. I only see functions making sense to be accepted > as annotations too (that's what Python do with annotations, @annotation symbol > is the same as symbol = annotation(symbol), but is quite a different language). There's another aspect to this. D's UDAs are a purely compile time system, attaching arbitrary metadata to specific symbols. The other UDA systems I'm aware of appear to be runtime systems. This implies the use cases will be different - how, I don't really know. But I don't know of any other compile time UDA system. Experience with runtime systems may not be as applicable. Another interesting data point is CTFE. C++11 has CTFE, but it was deliberately crippled and burdened with "constexpr". From what I read, this was out of fear that it would turn out to be an overused and overabused feature. Of course, this turned out to be a large error. One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say "I want to look in module X for symbols." Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? It's not quite analogous to exceptions, because arbitrary exceptions thrown from module X can flow through your code even though you have no idea module X even exists. I'm not sure what the correct answer is here, but I think the solutions are either to allow any old type as a UDA, or have @attribute structs or something along those lines. Just user defined types is a weird restriction. -- Simen
Re: UDAs - Restrict to User Defined Types?
On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright wrote: One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say "I want to look in module X for symbols." Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? Wasn't the @every_body_writes_their_names_like_this in C earlier in this thread yours? The problem is that without resorting to some kind of »unique« prefix convention, there will inevitably be modules X and Y which use the same annotation string for different purposes, creating problems if both modules are used together in the same code base (think passing a symbol from X to a template in Y, or an user wanting to create a type which is passed to both X and Y). I feel this is of particular significance here, as I think attributes are primarily going to be used in this kind of library context, where you allow the library user to mark their symbols up in a way that effects your library's behavior on said symbols. David
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/12 10:24 PM, Walter Bright wrote:
On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
I we were to allow for @foobar style UDA then "safe" would have to be
a reserved
keyword somehow. Otherwise I do not know what this would mean:
struct safe { }
@safe void foobar() { }
Yes, I agree this is a significant problem.
I think it's solvable. The basic approach would be to plop types "safe",
"nothrow" etc. in object.di and then let them just behave like all other
arguments.
Andrei
Re: a small study of "deprecate"
On Wed, 07 Nov 2012 15:26:20 -0600, Jonathan M Davis
wrote:
On Wednesday, November 07, 2012 14:16:26 monarch_dodra wrote:
I'm not going to propose a solution in this post, but I think
this is a good starting point for more discussion. Thoughts?
There's a relatively easy solution to this - just add the concept of
soft and
hard deprecation. Then, in additon to deprecate taking a message (which
it
finally does now), it could take a value indicating the level of
deprecation.
e.g.
deprecated("use X instead", soft) void func();
or
deprecated("use X instead", hard) void func();
or
deprecated("use X instead", false) void func();
or
deprecated("use X instead", warning) void func();
or whatever we decided to use for the argument to indicate the level of
deprecation. But soft would mean that only a warning was given, whereas
hard
would mean that you'd get an error. Then you make either soft or hard the
default (hard would keep the current behavior) so that if it's not
provided,
that's what's used. You then have normal -> soft -> hard -> gone.
The problem is that when this was brought up before, Walter didn't want
to do
anything ilke this, because he thought that it complicated the feature
too
much. He liked deprecated being nice and simple. It probably doesn't
help that
he doesn't like the idea of anything being deprecated in Phobos, and
Phobos
was the main reason that such a feature change was being requested.
So, I don't know what the odds of being able to get something like this
are.
It's certainly what _I_ would like to see implemented though.
- Jonathan M Davis
Walter seems to like simplicity to the point that you have to work around
many of the 'simple' features.
It's not 'simple' if you need to hack around it to get the same effect
that it should have had in the first place.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [ ArgumentList ] vs. @( ArgumentList )
Le 08/11/2012 00:14, nazriel a écrit : On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote: For User Defined Attributes. In the north corner we have the current champon: --- [ ArgumentList ] Pros: precedent with C# looks nice Cons: not so greppable parsing ambiguity with [array literal].func(); -- In the south corner, there's the challenger: @( ArgumentList ) Pros: looks like existing @attribute syntax no parsing problems Cons: not as nice looking -- No hitting below the belt! Let the games begin! @() with required (). So we will still have place for new language attributes like @rox etc ;) Language attribute must die :D
Re: UDAs - Restrict to User Defined Types?
On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright wrote: Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? What if you are using two different libraries in X that require you to annotate something with a string?
Re: UDAs - Restrict to User Defined Types?
I think restricting to user types makes sense because the type is
how you'd actually do anything with it.
My figuring is you'd generally do something like this:
foreach(t; __traits(getAttributes, foo))
static if(is(t == WhatICareAbout)) {
// use it
}
And if what you care about is something like string or int, how
do you know it semantically means what you think it means?
Re: What's C's biggest mistake?
On 11/7/12, "Ali Çehreli\" "@puremagic.com <"Ali Çehreli\" "@puremagic.com> wrote: > On Thursday, 24 December 2009 at 19:52:00 UTC, Walter Bright > wrote: >> http://www.reddit.com/r/programming/comments/ai9uc/whats_cs_biggest_mistake/ > > That article is not on Dr.Dobb's anymore: > >http://www.drdobbs.com/author/Walter-Bright > > Is there a copy somewhere else? > > Ali > http://web.archive.org/web/20100128003913/http://dobbscodetalk.com/index.php?option=com_myblog&show=Cs-Biggest-Mistake.html&Itemid=29
Re: std.signals2 proposal
> Having signals with weak reference semantics can be surprising > for a garbage collected language: AFAIK Java and C# use strong > reference semantics for observers. On the other hand one may want > strong reference semantics: if you have e.g. a button.click > listener, you don't want it to die prematurely, do you? Well I don't think it is a common pattern to create an object, connect it to some signal and drop every reference to it. On the other hand, if a signal kept a a strong reference to every object and you are done with it, you manually have to disconnect it from every signal in order not to have a memory leak, if the signals are long lived. Which comes pretty close to manual memory management (You don't get dangling pointers when doing things wrong, but signals keeping objects alive nobody cares about). So for me, especially in a garbage collected environment I would expect not to have to worry about such things. At least in my understanding it is very unintuitive to have a valid object whose only reference is a delegate contained in some signal. Having said that, there might be good reasons someone wants strong refs, so I will support in an easy and clean way, also because it comes at essentially no additional cost. I will just add a method like: void strongConnnect(void delegate(T1) dg) with dg being any delegate. (struct member function, lambda, class member, ...) with obvious semantics. This way you can use strongConnect if you have an observer you don't need any reference to, with its lifetime dependent on the signal and use the normal connect for carefree loose coupling. Best regards, Robert
UDAs - Restrict to User Defined Types?
Started a new thread on this. On 11/7/2012 3:05 AM, Leandro Lucarella wrote: > OK, that's another thing. And maybe a reason for listening to people having > more experience with UDAs than you. > > For me the analogy with Exceptions is pretty good. The issues an conveniences > of throwing anything or annotating a symbol with anything instead of just > type are pretty much the same. I only see functions making sense to be accepted > as annotations too (that's what Python do with annotations, @annotation symbol > is the same as symbol = annotation(symbol), but is quite a different language). There's another aspect to this. D's UDAs are a purely compile time system, attaching arbitrary metadata to specific symbols. The other UDA systems I'm aware of appear to be runtime systems. This implies the use cases will be different - how, I don't really know. But I don't know of any other compile time UDA system. Experience with runtime systems may not be as applicable. Another interesting data point is CTFE. C++11 has CTFE, but it was deliberately crippled and burdened with "constexpr". From what I read, this was out of fear that it would turn out to be an overused and overabused feature. Of course, this turned out to be a large error. One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say "I want to look in module X for symbols." Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? It's not quite analogous to exceptions, because arbitrary exceptions thrown from module X can flow through your code even though you have no idea module X even exists.
Re: [ ArgumentList ] vs. @( ArgumentList )
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote: For User Defined Attributes. In the north corner we have the current champon: --- [ ArgumentList ] Pros: precedent with C# looks nice Cons: not so greppable parsing ambiguity with [array literal].func(); -- In the south corner, there's the challenger: @( ArgumentList ) Pros: looks like existing @attribute syntax no parsing problems Cons: not as nice looking -- No hitting below the belt! Let the games begin! @() with required (). So we will still have place for new language attributes like @rox etc ;)
Re: std.signals2 proposal
On Wednesday, 7 November 2012 at 13:59:53 UTC, Kagamin wrote: On Tuesday, 6 November 2012 at 15:31:42 UTC, eskimo wrote: Signals are a way of a very loose coupling of components. This loose coupling is the reason why people usually expect weak reference semantics from signals. So people expect a signal connection to simply vanish when the observer object dies, instead of keeping it alive because it holds a reference to it. As long as you keep strong reference to the observer, it won't die. Having signals with weak reference semantics can be surprising for a garbage collected language: AFAIK Java and C# use strong reference semantics for observers. On the other hand one may want strong reference semantics: if you have e.g. a button.click listener, you don't want it to die prematurely, do you? Note that in C#, event subscribers are one of the most common sources of memory leaks. It's likely the most common memory leak period, but because in most situations you don't have tens of thousands of subscribers people don't notice. When you do though, things get messy.
Re: [ ArgumentList ] vs. @( ArgumentList )
Le 06/11/2012 20:18, Walter Bright a écrit : For User Defined Attributes. In the north corner we have the current champon: --- [ ArgumentList ] Pros: precedent with C# looks nice Cons: not so greppable parsing ambiguity with [array literal].func(); -- In the south corner, there's the challenger: @( ArgumentList ) Pros: looks like existing @attribute syntax no parsing problems Cons: not as nice looking -- No hitting below the belt! Let the games begin! About @() vs @[] the key point to me is that this is consistent with tuple syntax (which don't exists yet \o/). The important point to me is that @a is allowed.
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/07/2012 11:42 PM, Walter Bright wrote:
On 11/7/2012 1:16 PM, Timon Gehr wrote:
Text interpolation.
enum d = "c";
mixin(X!"abc@(d)ef"); // -> abccef
I use it mostly for code generation.
mixin(mixin(X!q{
if(@(a)) @(b);
}));
I see. How hard would it be to change it?
Not too hard, it can probably be automated.
I do not have issues with fixing up my code after breaking changes.
Even without this consideration, I still prefer
@[a,b,c]
Re: [ ArgumentList ] vs. @( ArgumentList )
Le 07/11/2012 22:16, Timon Gehr a écrit :
On 11/07/2012 09:20 PM, Walter Bright wrote:
On 11/7/2012 9:00 AM, Timon Gehr wrote:
On 11/06/2012 08:18 PM, Walter Bright wrote:
@( ArgumentList )
...
I do not like that one as I already use the syntax.
That currently isn't accepted by the D compiler - what are you already
using it for?
Text interpolation.
enum d = "c";
mixin(X!"abc@(d)ef"); // -> abccef
I use it mostly for code generation.
mixin(mixin(X!q{
if(@(a)) @(b);
}));
This can happen with any syntax addition. I usually use really bizantine
stuff when I do that (like <{@a@}>) so I'm sure to avoid the issue.
Can't a convention be decided on that ?
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/2012 1:30 PM, Simen Kjaeraas wrote: I think that's the first time I've heard someone suggest something be borrowed from VB. :p Of course we all take it for granted that Basic sux and does everything wrong, and this has been going on for 30+ years. But in one of the early design sessions on D, I'd ask "Since Basic sux, why is its string handling so nice & convenient, and C's string handling is such a misery?" So Basic did provide some motivation.
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/2012 1:16 PM, Timon Gehr wrote:
Text interpolation.
enum d = "c";
mixin(X!"abc@(d)ef"); // -> abccef
I use it mostly for code generation.
mixin(mixin(X!q{
if(@(a)) @(b);
}));
I see. How hard would it be to change it?
Re: DConf 2013 to be recorded
On Wednesday, 7 November 2012 at 21:38:58 UTC, Nick Sabalausky wrote: On Tue, 06 Nov 2012 07:11:19 -0800 Walter Bright wrote: That'd work fine. It doesn't need to be 320 bit quality! Yup, AIUI mp3 was designed for voice anyway, that's why music needs to be cranked up to ridiculous bitrates to not sound shitty when you're using mp3 instead of a proper general-purpose audio codec like vorbis or aac. Both Vorbis and MP3 can be set as VBR (Variable Bit Rate), however I would think that's post processing; If possible I would think you get as high of quality as you can reasonably get, then downgrade it afterwards. If you got 50Gb of space for audio, why not record at 320kbits? Thank heavens for MPEG-4 (and AVC/h.264), otherwise video would still be difficult to transmit over the internet at decent speeds. If I attend and that's very likely (unless something huge happens... like my death...) then I would bring an external drive or two, meaning drive space during the recording and time there wouldn't be an issue; Although having a backup in case one of the drives fails seems important at that point (losing the only copy would be quite annoying to everyone).
Re: Transience of .front in input vs. forward ranges
On Wed, Nov 07, 2012 at 10:40:32PM +0100, Jonathan M Davis wrote: > On Wednesday, November 07, 2012 21:31:13 deadalnix wrote: > > OK, overall, .peekFront seems like a good idea. Something I'm afraid > > with .peekFront is code duplication. > > > > Let's take the joiner example. Joiner's transientness depend on its > > source transientness. This seems to me like a very common case for > > transformer ranges. If we choose the .peekFront, the naive thing to > > do is to implement the same algorithm twice, using front and > > peekFront, which is code duplication, and usually a bad idea. > > Why would you need to duplicate anything?. If you can implement it > using peekFront, then you use peekFront. If you can't, you use front. > And anything which uses front when you could have used peekFront will > still work. Also, if a free function peekFront which forwards to front > is defined, then all range- based functions can use peekFront if they > need it regardless of whether a range defines it (it's just that it > would do the same as front in the case where the range didn't define > it). [...] Yeah, UFCS will kick in if the range itself doesn't define peekFront, then the free function peekFront will simply call the range's .front instead. So basically: if an algo needs .front to be persistent, they use .front. If they don't care if .front is persistent, they use .peekFront. T -- You are only young once, but you can stay immature indefinitely. -- azephrahel
Re: [RFC] Fix `object.destroy` problem
08.11.2012 1:20, Denis Shelomovskij пишет: IMHO we have a huge design problem with `object.destroy`. Please, carefully read "Now the worst thing with `object.destroy`" section of the pull 344 about it: https://github.com/D-Programming-Language/druntime/pull/344 Just my own post: The first time I looked at `destroy` implementation (yes, I almost always read sources as documentation often gives a small part of needed information and in this particular case it really gives nothing) I considered it strange. From the second look when I completely understood what is it really doing I was in shock how such inconsistent and dangerous thing could ever be made. So finally I found time and did the pull. And it was obvious that everybody understand the problem or, if someone hasn't already read `destroy` implementation, he will see the diff and will agree in the moment. But as it isn't the first time I think so, I provided a detailed description about [obvious] `destroy` problems. A response was about: "What is the problem with `destroy`? Why are you doing it?". So here is this NG thread and, probably, I will hear even more "Why are you doing it?" questions which I don't know how to answer as I already listened all my reasons in pull description and can't add a lot. And probably will never understand why people asking such questions doesn't argue their opinion by proofing that my arguments are incorrect or irrelevant. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [RFC] Add an operator for ranges to D. Pros and cons?
bearophile wrote: > Dejan Lekic: > >> I already did try using the tilda operator for a while, then I >> realised that >> people are getting confused thinking the line is concatinating >> strings, then >> then realise those are ranges... > > "~" is used for all arrays (while array.Appender used put for > mysterious reasons). If more and more D code starts using "~" to > concatenate ranges or arrays, I think D programmers will get used > to this more general meaning. > > Bye, > bearophile ~ with arrays has different semantics I fear. -- Dejan Lekic - http://dejan.lekic.org
Re: [RFC] Add an operator for ranges to D. Pros and cons?
> > auto something = outRange(bazRange(barRange(fooRange(inRange, param)), param1, > param2)); It looks readable in this case, but to have it clean like that your parameters should be variables, otherwise imagine what would be if in all that you have calls to some functions to obtain argument for some of those ranges: ...fooRange(someObject.getInRange(), foo!(bla)(param1...)),param1... If I was the author, all would be fine, but if I give that code to someone, he/she will need time to understand what is actually happening... -- Dejan Lekic - http://dejan.lekic.org
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wed, 07 Nov 2012 19:17:20 +0100 Jacob Carlborg wrote: > On 2012-11-07 16:51, Nick Sabalausky wrote: > > > vote++ > > > > It has all the benefits of '@(...)' (which are very compelling on > > their own), but also has the *ONE* benefit of '[...]': Much less > > getting lost in stupid parenthesis, as demonstrated here: > > http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org > > This is how that example would look like with my syntax: > > http://pastebin.com/8Ve5KS49 > > I think it looks better in most cases > Well, I'm in favor of the @attr shortcut regardless of @[] vs @().
Re: Transience of .front in input vs. forward ranges
On Wednesday, November 07, 2012 21:31:13 deadalnix wrote: > OK, overall, .peekFront seems like a good idea. Something I'm afraid > with .peekFront is code duplication. > > Let's take the joiner example. Joiner's transientness depend on its > source transientness. This seems to me like a very common case for > transformer ranges. If we choose the .peekFront, the naive thing to do > is to implement the same algorithm twice, using front and peekFront, > which is code duplication, and usually a bad idea. Why would you need to duplicate anything?. If you can implement it using peekFront, then you use peekFront. If you can't, you use front. And anything which uses front when you could have used peekFront will still work. Also, if a free function peekFront which forwards to front is defined, then all range- based functions can use peekFront if they need it regardless of whether a range defines it (it's just that it would do the same as front in the case where the range didn't define it). - Jonathan M Davis
Re: DConf 2013 to be recorded
On Tue, 06 Nov 2012 07:11:19 -0800 Walter Bright wrote: > On 11/6/2012 6:56 AM, Iain Buclaw wrote: > > I've got a Zoom H1, so it's a lovely little pocket device that can > > do about 50 hours recording (or 500 if I switch it to mp3 format). > > That'd work fine. It doesn't need to be 320 bit quality! > Yup, AIUI mp3 was designed for voice anyway, that's why music needs to be cranked up to ridiculous bitrates to not sound shitty when you're using mp3 instead of a proper general-purpose audio codec like vorbis or aac.
Re: What's C's biggest mistake?
On Thursday, 24 December 2009 at 19:52:00 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/ai9uc/whats_cs_biggest_mistake/ That article is not on Dr.Dobb's anymore: http://www.drdobbs.com/author/Walter-Bright Is there a copy somewhere else? Ali
Re: Const ref and rvalues again...
On 11/07/2012 07:48 PM, martin wrote: On Wednesday, 7 November 2012 at 18:07:27 UTC, Timon Gehr wrote: You do not give a justification. I find it very useful to know that an argument won't be modified. That is unrelated and does not necessarily follow, but that it does in some cases is the main reason why const is useful even though it weakens encapsulation. Let's look at encapsulation this way: suppose my function is a colleague and his job is to summarize a book I lend him (my reference parameter). I don't care how he does it as long as the summary (function result) is what I expect. But I do care about my book if I plan on using it afterwards (so in case the argument is an lvalue used later on) - will I have to check it for defects, coffee spillings etc., or can I be sure it's exactly as it was before (const)? You can pass him an object that does not support operations you want to preclude. He does not have to _know_, that your book is not changed when he reads it. This is an implementation detail. In fact, you could make the book save away his reading schedule without him noticing. This is how I see it. The thing about mutable rvalue references would be unknown or unthought-of side effects: what if the book is the same, but my colleague, a known psychopath, killed the author (a property of the book reference, a reference itself)? I don't use the book anymore, okay (it was an rvalue after all), but it may still be worth knowing that the author has gone. Due to the transitiveness of const, the (const) author would still be alive if the book reference had been const. I'd assume that the book you pass him would not support changing the author. You have to do that anyway if it the operation is not at least 'const pure' and you need to guarantee that no other thread is in fact modifying the data. I think we can agree that knowing the parameters aren't touched does help a lot in this case. Maybe, but the fact that we know it harms encapsulation.
Re: [ ArgumentList ] vs. @( ArgumentList )
On 2012-11-07, 18:03, John Chapman wrote: On Wednesday, 7 November 2012 at 11:29:16 UTC, Simen Kjaeraas wrote: On 2012-12-07 11:11, Timon Gehr wrote: On 11/07/2012 09:28 AM, Simen Kjaeraas wrote: On 2012-19-07 09:11, John Chapman wrote: Personally, I also like . I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: bar)> This example does not show that they cause problems. Not true. The compiler certainly can handle it, but a programmer could easily be confused. I'm not putting it forward for consideration, but there is a precedent in Visual Basic - http://msdn.microsoft.com/en-US/library/h3z05kek%28v=vs.80%29.aspx I think that's the first time I've heard someone suggest something be borrowed from VB. :p -- Simen
Re: a small study of "deprecate"
On Wednesday, November 07, 2012 15:05:05 deadalnix wrote: > Here is how I see it (and all language fail at that as far as my > knowledge goes). > > Deprecation comes with a date and a message. > > Before the date, the dev is presented with the deprecation message when > compiling. The message explain why the function is deprecated and what > to use instead. > > After the date, the message pops, but now it is an error (unless some > flag is used). > > At some point the function may be removed. Date-based stuff was discussed previously and rejected. One of the major reasons that it doesn't work is that there are times when you want to deprecate based on versions rather than dates. But the _really_ big reason not to do that is that if compile my code with version X of the compiler, it should _always_ compile with version X of the compiler. It would result in a big maintenance problem if you couldn't go back and rebuild older versions of a program (or just an older program) with the compiler that it was originally compiled with. It's one thing if it won't compile with a newer version of the compiler or a newer version of the library, but not compiling with the same version that it was developed with causes big problems later down the line, especially if you're dealing with a program that doesn't get worked on very often. So, while giving a message that a particular symbol is going to be deprecated on a certain date is fine, having the compiler deprecate it for you at that date is going to cause problems. - Jonathan M Davis
Re: a small study of "deprecate"
On Wednesday, November 07, 2012 14:16:26 monarch_dodra wrote:
> I'm not going to propose a solution in this post, but I think
> this is a good starting point for more discussion. Thoughts?
There's a relatively easy solution to this - just add the concept of soft and
hard deprecation. Then, in additon to deprecate taking a message (which it
finally does now), it could take a value indicating the level of deprecation.
e.g.
deprecated("use X instead", soft) void func();
or
deprecated("use X instead", hard) void func();
or
deprecated("use X instead", false) void func();
or
deprecated("use X instead", warning) void func();
or whatever we decided to use for the argument to indicate the level of
deprecation. But soft would mean that only a warning was given, whereas hard
would mean that you'd get an error. Then you make either soft or hard the
default (hard would keep the current behavior) so that if it's not provided,
that's what's used. You then have normal -> soft -> hard -> gone.
The problem is that when this was brought up before, Walter didn't want to do
anything ilke this, because he thought that it complicated the feature too
much. He liked deprecated being nice and simple. It probably doesn't help that
he doesn't like the idea of anything being deprecated in Phobos, and Phobos
was the main reason that such a feature change was being requested.
So, I don't know what the odds of being able to get something like this are.
It's certainly what _I_ would like to see implemented though.
- Jonathan M Davis
[RFC] Fix `object.destroy` problem
IMHO we have a huge design problem with `object.destroy`. Please, carefully read "Now the worst thing with `object.destroy`" section of the pull 344 about it: https://github.com/D-Programming-Language/druntime/pull/344 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/07/2012 09:20 PM, Walter Bright wrote:
On 11/7/2012 9:00 AM, Timon Gehr wrote:
On 11/06/2012 08:18 PM, Walter Bright wrote:
@( ArgumentList )
...
I do not like that one as I already use the syntax.
That currently isn't accepted by the D compiler - what are you already
using it for?
Text interpolation.
enum d = "c";
mixin(X!"abc@(d)ef"); // -> abccef
I use it mostly for code generation.
mixin(mixin(X!q{
if(@(a)) @(b);
}));
Re: deprecate deprecated?
On 2012-11-07 20:32, deadalnix wrote: I'm talking about the ability for the macro to modify the macroed code, not only to wrap it. I'm still not entirely sure what you mean but in most AST macro systems in other languages like Sacal, Nimrod and Nemerle you will get the complete AST of the function and can do whatever you want with it. It's just happens so that in this example it's enough to wrap the function. Actually, my "implementation" didn't wrap the function, it injected the "static assert" into the function body. -- /Jacob Carlborg
Re: a small study of "deprecate"
On Wednesday, 7 November 2012 at 14:05:06 UTC, deadalnix wrote: Here is how I see it (and all language fail at that as far as my knowledge goes). Deprecation comes with a date and a message. Before the date, the dev is presented with the deprecation message when compiling. The message explain why the function is deprecated and what to use instead. After the date, the message pops, but now it is an error (unless some flag is used). At some point the function may be removed. The message should refer the reader to a resource url for more details on the specific depreciation. --rt
Re: Const ref and rvalues again...
On Wednesday, 7 November 2012 at 14:07:31 UTC, martin wrote:
T g() {
T temp;
temp.createResource();
return temp; // D already moves temp!
// 'Named Return Value Optimization'
}
OK, it seems to be working as you describe.
The main question I have is if I can rely on this behaviour as a
feature provided by the languge specification vs an opportunistic
compiler optimization that may or may not happen depending on the
implementation?
The general problem I'm having with with D, is I need a gaurantee
that certain behaviors will always be performed when moves/copies
are done, but it's just not clear if this is the case or not.
There seems to be a lack of a concise language specification, or
is there one defined somewhere?
You could implement a copy constructor 'this(this)' in your
struct T and see when it is invoked to check when an instance
is actually copied. I'd expect that invoking 'f(g());' with
above implementation doesn't copy anything.
I am doing that, but I cannpt seem to hook into the part where a
move does an "init" on the struct or class. I sort-of can see it
though, if I set a member value to a known state before the move,
then display it to console or log after the move during
destruction. If it was init'ed then I'll see the default value,
and this seems to be happening as described.
Anyway, what I was hoping for with "auto ref" was for the
compiler to selectively decide if the ref part should be used or
not depending on the situation, rather than me manually writing
two functions to do the exact same thing. What's discussed in
here about auto ref is something else, although I agree it is
definitely needed.
--rt
Re: [ ArgumentList ] vs. @( ArgumentList )
Le 07/11/2012 21:24, Walter Bright a écrit :
On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
I we were to allow for @foobar style UDA then "safe" would have to be
a reserved
keyword somehow. Otherwise I do not know what this would mean:
struct safe { }
@safe void foobar() { }
Yes, I agree this is a significant problem.
As a cross topic answer, I'll mention that allowing anything to be an
attribute is likely to be a bad idea, and that way to solve that are
already discussed.
Re: Transience of .front in input vs. forward ranges
Le 07/11/2012 19:24, H. S. Teoh a écrit : On Tue, Nov 06, 2012 at 10:03:56PM +0100, deadalnix wrote: Le 06/11/2012 07:49, Andrei Alexandrescu a écrit : On 11/6/12 4:36 AM, H. S. Teoh wrote: Hmm. Another idea just occurred to me. The basic problem here is that we are conflating two kinds of values, transient and persistent, under a single name .front. What if we explicitly name them? Say, .copyFront for the non-transient value and .refFront for the transient value (the names are unimportant right now, let's consider the semantics of it). We could transfer that matter to the type of .front itself, i.e. define a function copy(x) that returns e.g. x for for string and x.dup for char[] etc. There would be problems on e.g. defining copy for structs with pointer and class reference fields etc. One quite simple approach would be to define (on the contrary) .peekFront, which means "yeah, I'd like to take a peek at the front but I don't plan to store it anywhere". That would entail we define eachLine etc. to return string from .front and char[] from .peekFront, and deprecate byLine. [...] Is it possible to have the pro and cons of peekFront vs transient ? I'll give it a shot, since nobody else is replying: Both .peekFront and .transient require at least existing transient ranges to be modified, as well as algorithms that can take advantage of them. - For .peekFront, existing transient ranges' .front is just renamed to .peekFront, and we add a new .front which returns the .dup (or otherwise copy) of .peekFront. For .transient, we need to write a .transient method that returns a wrapper struct whose .front is transient. * So .peekFront is slightly simpler in this case. Agreed ! - For .peekFront, algorithms that can handle transience can simply have all occurrences of .front replaced with .peekFront. Whereas for .transient, they will need to modified to explicitly call .transient, save that range, and use that instead of the passed-in range. * So .peekFront is slightly simpler in this case. .transient seems simpler to me in this case. Adding one line is easier than replacing all occurrences of something. - For .peekFront, algorithms that *can't* handle transience will have to be rewritten. Same goes for .transient. The redeeming factor in both cases is that algorithms that aren't rewritten yet will continue to work as before, just a bit slower. They will also begin to work correctly with transient ranges even _before_ being rewritten, whereas right now they're broken. * Here, .peekFront and .transient are equal in terms of effort required. Indeed. - For .peekFront, the .front of *any* range is guaranteed to be non-transient, so we never have to worry about whether a particular range's .front is transient or not. User code has no possibility of passing a transient range into an algorithm that cannot handle it. For .transient, the .front of ranges is non-transient by default, but once you call .transient on it, you get a range whose .front is transient. There is a small possibility of wrong user code that passes a .transient range to an algorithm that can't handle it. * So .peekFront is slightly safer on this point. These are the points that I can think of, off the top of my head. Are there any others? Either way, both .peekFront and .transient requires rewriting currently transient ranges (which AFAIK is only byLine) and any algorithms that should be able to handle transience (there are a few I can think of, like std.algorithm.joiner, std.array.join, and maybe NWayUnion and writeln& co.). We can't do better than this if we're going to support transience at all. I note, though, that the list of algorithms that need to be updated is shorter (perhaps significantly so) than the list of currently-broken algorithms that I posted earlier, because many of the algorithms in that list *cannot* be implemented to handle transience. E.g. there is no way to implement uniq on a transient input range since there's no way to save the previous value seen, so there's no way to compare two adjacent values. Likewise, findAdjacent cannot be implemented for transient ranges for the same reason. Once these are eliminated from the list, there should only be a few algorithms left. (And I already have a version of joiner that works correctly with transient ranges.) OK, overall, .peekFront seems like a good idea. Something I'm afraid with .peekFront is code duplication. Let's take the joiner example. Joiner's transientness depend on its source transientness. This seems to me like a very common case for transformer ranges. If we choose the .peekFront, the naive thing to do is to implement the same algorithm twice, using front and peekFront, which is code duplication, and usually a bad idea. Is a solution known here ? Could alias template parameter help ? I'm not sure what is the solution, but if one exist, I'm sold for .pe
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/2012 9:00 AM, Timon Gehr wrote: On 11/06/2012 08:18 PM, Walter Bright wrote: @( ArgumentList ) ... I do not like that one as I already use the syntax. That currently isn't accepted by the D compiler - what are you already using it for?
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
I we were to allow for @foobar style UDA then "safe" would have to be a reserved
keyword somehow. Otherwise I do not know what this would mean:
struct safe { }
@safe void foobar() { }
Yes, I agree this is a significant problem.
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/7/2012 2:12 AM, Timon Gehr wrote: On 11/07/2012 09:28 AM, Simen Kjaeraas wrote: On 2012-19-07 09:11, John Chapman wrote: Personally, I also like . I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: bar)> This example does not show that they cause problems. < 3, 4>7 > does.
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wednesday, 7 November 2012 at 09:23:44 UTC, Jonathan M Davis
wrote:
On Wednesday, November 07, 2012 10:13:47 Jonas Drewsen wrote:
My vote goes to @(a,b,c) and @a @b @c.
I never understood why some builtin storage class keywords
have @
in front of them (e.g. @property, @safe, @disable) and some
don't
(e.g. pure, nothrow).
IMHO the cleanest design would be to have builtins as plain
keywords (ie. no @ in front). And then @xxx is reserved for
UDA.
I understand that this would be a breaking change and not
likely
to happen - just want to know the reasoning behind it.
It mainly came down to not wanting to add new keywords. By
using @safe instead
of safe, safe could still be used as a variable or function or
whatnot. There
was some discussion of which should have @ on them on which not
(e.g. nothrow
vs @nothrow was debated), but the decision was fairly
arbitrary. If anything
though, had we not cared about breaking code or whether D
looked similar to
other languages, we probably would have made _all_ attributes
start with @
(including stuff like @public). It would have been wonderfully
consistent that
way, but it wasn't ultimately deemed a good idea.
So, basically, @ was introduced to avoid adding more keywords.
It certainly
makes sense to extend it for using with user defined
attributes, but that
wasn't really the original intention.
- Jonathan M Davis
I we were to allow for @foobar style UDA then "safe" would have
to be a reserved keyword somehow. Otherwise I do not know what
this would mean:
struct safe { }
@safe void foobar() { }
/Jonas
Re: [ ArgumentList ] vs. @( ArgumentList )
Le 07/11/2012 19:44, Tobias Pankrath a écrit : Second: When the time comes, we'll hopefully have enough reengineering tools that can fully qualify any conflicting uses of a name automatically. As long as SURPRISE feature are added to master, that is not gonna happen.
Re: deprecate deprecated?
Le 07/11/2012 18:58, Jacob Carlborg a écrit : On 2012-11-07 15:08, deadalnix wrote: This is nice, but lack the possible to explore the internal of the function and to surgery in it :D Still a step forward. I'm not entirely sure I understand. Do you mean that you won't see the output of the macro? In that case the compiler should have a flag for outputting the result of a macro. I'm talking about the ability for the macro to modify the macroed code, not only to wrap it.
Re: [RFC] Add an operator for ranges to D. Pros and cons?
On Wednesday, November 07, 2012 14:07:12 Dejan Lekic wrote: > Therefore I would like to know what do you think about the idea > of having additional operator exclusively made for ranges? This > operator would make it obvious that data are "streamed" (lack of > better term) among ranges. As far as I can tell, it adds zero functionality. It's purely a matter of trying to create cleaner looking code. That being the case, I would think that suggestions like auto something = inRange .fooRange(param) .barRange() .bazRange(param1, param2) .outRange(); solve the problem quite nicely, though I honestly, I have no problem with simply doing auto something = outRange(bazRange(barRange(fooRange(inRange, param)), param1, param2)); though with that many chained items and several of them taking multiple parameters, something like auto tempSomething = barRange(fooRange(inRange, param)); auto something = outRange(bazRange(tempSomething, param1, param2)); would probably be better. The first approach using UFCS seems rather popular though, and it's _very_ clean. My main gripe with it is that the flow is backwards, but I seem to be in the minority in thinking that. Regardless, there are ways to format code so that it's quite clean without making any language changes. I don't see how adding an operator would really help. It just complicates the language further. - Jonathan M Davis
Re: Const ref and rvalues again...
On Wednesday, 7 November 2012 at 18:07:27 UTC, Timon Gehr wrote: You do not give a justification. I find it very useful to know that an argument won't be modified. That is unrelated and does not necessarily follow, but that it does in some cases is the main reason why const is useful even though it weakens encapsulation. Let's look at encapsulation this way: suppose my function is a colleague and his job is to summarize a book I lend him (my reference parameter). I don't care how he does it as long as the summary (function result) is what I expect. But I do care about my book if I plan on using it afterwards (so in case the argument is an lvalue used later on) - will I have to check it for defects, coffee spillings etc., or can I be sure it's exactly as it was before (const)? This is how I see it. The thing about mutable rvalue references would be unknown or unthought-of side effects: what if the book is the same, but my colleague, a known psychopath, killed the author (a property of the book reference, a reference itself)? I don't use the book anymore, okay (it was an rvalue after all), but it may still be worth knowing that the author has gone. Due to the transitiveness of const, the (const) author would still be alive if the book reference had been const. You have to do that anyway if it the operation is not at least 'const pure' and you need to guarantee that no other thread is in fact modifying the data. I think we can agree that knowing the parameters aren't touched does help a lot in this case.
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wednesday, 7 November 2012 at 18:28:54 UTC, Regan Heath wrote: This is how that example would look like with my syntax: http://pastebin.com/8Ve5KS49 I think it looks better in most cases For comparison the same again using @[]: http://pastebin.com/vgjLSXMv I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!). Here it is with no highlighting: http://pastebin.com/08judqWj R I like Jacobs proposal more. On many keyboards are [ and ] notoriously hard to type . Despite that: please make any form of brackets optional. I wouldn't consider any possibly breaking changes in the future for two reasons: First: New buildin UDA can go into modules and adhere to normal scoping rules. Second: When the time comes, we'll hopefully have enough reengineering tools that can fully qualify any conflicting uses of a name automatically.
Re: [RFC] Add an operator for ranges to D. Pros and cons?
Dejan Lekic: I already did try using the tilda operator for a while, then I realised that people are getting confused thinking the line is concatinating strings, then then realise those are ranges... "~" is used for all arrays (while array.Appender used put for mysterious reasons). If more and more D code starts using "~" to concatenate ranges or arrays, I think D programmers will get used to this more general meaning. Bye, bearophile
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wed, Nov 07, 2012 at 06:28:54PM -, Regan Heath wrote: > On Wed, 07 Nov 2012 18:17:20 -, Jacob Carlborg wrote: > > >On 2012-11-07 16:51, Nick Sabalausky wrote: > > > >>vote++ > >> > >>It has all the benefits of '@(...)' (which are very compelling on > >>their own), but also has the *ONE* benefit of '[...]': Much less > >>getting lost in stupid parenthesis, as demonstrated here: > >>http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org > > > >This is how that example would look like with my syntax: > > > >http://pastebin.com/8Ve5KS49 > > > >I think it looks better in most cases > > For comparison the same again using @[]: > http://pastebin.com/vgjLSXMv > > I actually think the pastebin syntax highlighting makes both of them > look worse (why the horrid green!). > > Here it is with no highlighting: > http://pastebin.com/08judqWj [...] Hmm. Having seen both @() and @[] in actual sample code, I have to say that @() is visually less distracting and more pleasant to read (to me, anyway, YMMV). I don't like @[] because it just stands out too much. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wed, 07 Nov 2012 18:17:20 -, Jacob Carlborg wrote: On 2012-11-07 16:51, Nick Sabalausky wrote: vote++ It has all the benefits of '@(...)' (which are very compelling on their own), but also has the *ONE* benefit of '[...]': Much less getting lost in stupid parenthesis, as demonstrated here: http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org This is how that example would look like with my syntax: http://pastebin.com/8Ve5KS49 I think it looks better in most cases For comparison the same again using @[]: http://pastebin.com/vgjLSXMv I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!). Here it is with no highlighting: http://pastebin.com/08judqWj R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [RFC] Add an operator for ranges to D. Pros and cons?
bearophile wrote: > Dejan Lekic: > >> Dear D community, I do not know about You, but I certainly do >> not like writing code like: >> >> inRange.fooRange(param).barRange. >> .bazRange(param1, param2).outRange; > > I suggest to format it this way, it's more readable: > > auto something = inRange > .fooRange(param) > .barRange() > .bazRange(param1, param2) > .outRange(); > > >> Therefore I would like to know what do you think about the idea >> of having additional operator exclusively made for ranges? This >> operator would make it obvious that data are "streamed" (lack >> of better term) among ranges. >> >> The first name I could come up with was "opArrow" but "opData" >> could also be okay, and operator would be either "~>" or "->". >> >> This would give us an obvious, unambiguous statement: >> >> Console.in ~> filter1(param) ~> fooRange ~> Console.out; >> // Console is an imaginary class/struct > > I think it doesn't give a significant improvement. But maybe > there are more interesting use cases. > > I'd like D ranges to support the "~" (using a template mixin to > give them such operator), that acts like chain. So instead of > writing: > > range1.chain(range2) > > You write: > > range1 ~ range2 > > It's also nice to have lazy lists, maybe based on fibers, with > few operators to concat them, etc. > > Bye, > bearophile I already did try using the tilda operator for a while, then I realised that people are getting confused thinking the line is concatinating strings, then then realise those are ranges... That is exactly the reason why I asked the D community what they think about having a new operator only for ranges... I also do what you suggest quite a lot. In fact I almost write it the same way you do in your example. But think about potential scenario when you give parameters as members of some structure: auto something = inRange .fooRange(someObject.someMember.membersMember) .barRange(SomeClass.staticMember) .bazRange(/* etc */) .jarRange(param1, param2) .outRange(/* etc */); Moreover, what if developer does not add "Range" to the name (typical case)? Imagine confusion with such UFCS methods and properties... -- Dejan Lekic - http://dejan.lekic.org
Re: Transience of .front in input vs. forward ranges
On Tue, Nov 06, 2012 at 10:03:56PM +0100, deadalnix wrote: > Le 06/11/2012 07:49, Andrei Alexandrescu a écrit : > >On 11/6/12 4:36 AM, H. S. Teoh wrote: > >>Hmm. Another idea just occurred to me. The basic problem here is > >>that we are conflating two kinds of values, transient and > >>persistent, under a single name .front. What if we explicitly name > >>them? Say, .copyFront for the non-transient value and .refFront for > >>the transient value (the names are unimportant right now, let's > >>consider the semantics of it). > > > >We could transfer that matter to the type of .front itself, i.e. > >define a function copy(x) that returns e.g. x for for string and > >x.dup for char[] etc. There would be problems on e.g. defining copy > >for structs with pointer and class reference fields etc. > > > >One quite simple approach would be to define (on the contrary) > >.peekFront, which means "yeah, I'd like to take a peek at the front > >but I don't plan to store it anywhere". That would entail we define > >eachLine etc. to return string from .front and char[] from > >.peekFront, and deprecate byLine. [...] > Is it possible to have the pro and cons of peekFront vs transient ? I'll give it a shot, since nobody else is replying: Both .peekFront and .transient require at least existing transient ranges to be modified, as well as algorithms that can take advantage of them. - For .peekFront, existing transient ranges' .front is just renamed to .peekFront, and we add a new .front which returns the .dup (or otherwise copy) of .peekFront. For .transient, we need to write a .transient method that returns a wrapper struct whose .front is transient. * So .peekFront is slightly simpler in this case. - For .peekFront, algorithms that can handle transience can simply have all occurrences of .front replaced with .peekFront. Whereas for .transient, they will need to modified to explicitly call .transient, save that range, and use that instead of the passed-in range. * So .peekFront is slightly simpler in this case. - For .peekFront, algorithms that *can't* handle transience will have to be rewritten. Same goes for .transient. The redeeming factor in both cases is that algorithms that aren't rewritten yet will continue to work as before, just a bit slower. They will also begin to work correctly with transient ranges even _before_ being rewritten, whereas right now they're broken. * Here, .peekFront and .transient are equal in terms of effort required. - For .peekFront, the .front of *any* range is guaranteed to be non-transient, so we never have to worry about whether a particular range's .front is transient or not. User code has no possibility of passing a transient range into an algorithm that cannot handle it. For .transient, the .front of ranges is non-transient by default, but once you call .transient on it, you get a range whose .front is transient. There is a small possibility of wrong user code that passes a .transient range to an algorithm that can't handle it. * So .peekFront is slightly safer on this point. These are the points that I can think of, off the top of my head. Are there any others? Either way, both .peekFront and .transient requires rewriting currently transient ranges (which AFAIK is only byLine) and any algorithms that should be able to handle transience (there are a few I can think of, like std.algorithm.joiner, std.array.join, and maybe NWayUnion and writeln & co.). We can't do better than this if we're going to support transience at all. I note, though, that the list of algorithms that need to be updated is shorter (perhaps significantly so) than the list of currently-broken algorithms that I posted earlier, because many of the algorithms in that list *cannot* be implemented to handle transience. E.g. there is no way to implement uniq on a transient input range since there's no way to save the previous value seen, so there's no way to compare two adjacent values. Likewise, findAdjacent cannot be implemented for transient ranges for the same reason. Once these are eliminated from the list, there should only be a few algorithms left. (And I already have a version of joiner that works correctly with transient ranges.) T -- Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder
Re: [ ArgumentList ] vs. @( ArgumentList )
On 2012-11-07 16:51, Nick Sabalausky wrote: vote++ It has all the benefits of '@(...)' (which are very compelling on their own), but also has the *ONE* benefit of '[...]': Much less getting lost in stupid parenthesis, as demonstrated here: http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org This is how that example would look like with my syntax: http://pastebin.com/8Ve5KS49 I think it looks better in most cases -- /Jacob Carlborg
Re: [ ArgumentList ] vs. @( ArgumentList )
"Regan Heath" wrote > On Wed, 07 Nov 2012 15:51:50 -, Nick Sabalausky > wrote: > >> On Tue, 06 Nov 2012 22:53:36 +0100 >> Artur Skawina wrote: >>> >>> "@[ArgumentList]". >>> >> >> vote++ >> >> It has all the benefits of '@(...)' (which are very compelling on >> their own), but also has the *ONE* benefit of '[...]': Much less >> getting lost in stupid parenthesis, as demonstrated here: >> http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org > > I hadn't replied to this thread earlier because I didn't have a strong > opinion either way, but, this suggestion appears to be the best of both > worlds. So.. > > vote++ +1
Re: deprecate deprecated?
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote: I know there's been some long term unhappiness about the deprecated attribute - it's all-or-nothing approach, poor messages, etc. Each change in it changes the language and the compiler. Perhaps it could be done with a user defined attribute instead? Anyone want to take on the challenge? Good plan. On a side note when can we expect some progress on stabilizing the language and fixing ~2000 bugs? After a couple of more random unnecessary breaking changes, or do you anticipate it happening before that?
Re: Const ref and rvalues again...
On 11/07/2012 06:52 PM, martin wrote: On Wednesday, 7 November 2012 at 16:57:47 UTC, Timon Gehr wrote: That is the main thing, but C++ also has a 'mutable' keyword. Right, I forgot this inconspicuous little keyword. It really is a huge hole in C++'s const system. If your struct doesn't support any const operations, it most likely has good reasons not to. Either that, or someone hasn't bothered to annotate. Hehe, yeah, the latter being more likely. You got it exactly reverse. const harms encapsulation because it exposes some details about implementations. It is often not applicable in sufficiently dynamic code. I don't see it that way. You do not give a justification. I find it very useful to know that an argument won't be modified. That is unrelated and does not necessarily follow, but that it does in some cases is the main reason why const is useful even though it weakens encapsulation. Example: suppose we have a large array (static array or wrapped in a struct) and need it as input for some independent operations. By knowing it won't be touched (passing by const ref) it is immediately clear that the operations can be run in parallel. Otherwise, one would need to go through the operations' implementation to determine if parallelization is possible. You have to do that anyway if it the operation is not at least 'const pure' and you need to guarantee that no other thread is in fact modifying the data. But even then I do not see how that helps encapsulation. Naive parallelization is just one of the examples that shows that encapsulation can be harmful in some specific cases. You do not see issues with changing the interface based on implementation details? I find it okay to require all possible changes to an argument passed by reference to be required to be directly visible by the caller, just to prevent accidentally missing side effects. Suppose a function takes a const reference parameter and is called at a site using an rvalue. After some time, that function is updated so that its parameter is or may be changed, changing the const ref parameter to a ref parameter. That may lead to big issues for the call sites. A compiler error would make sure the affected call sites are inspected and updated instead of potentially introducing regressions. Often there is nothing to be seen for the caller. (lazy initialization, caching, internal state update part of a larger computation, ...)
Re: deprecate deprecated?
On 2012-11-07 15:08, deadalnix wrote: This is nice, but lack the possible to explore the internal of the function and to surgery in it :D Still a step forward. I'm not entirely sure I understand. Do you mean that you won't see the output of the macro? In that case the compiler should have a flag for outputting the result of a macro. -- /Jacob Carlborg
Re: Const ref and rvalues again...
On Wednesday, 7 November 2012 at 16:57:47 UTC, Timon Gehr wrote: That is the main thing, but C++ also has a 'mutable' keyword. Right, I forgot this inconspicuous little keyword. It really is a huge hole in C++'s const system. If your struct doesn't support any const operations, it most likely has good reasons not to. Either that, or someone hasn't bothered to annotate. Hehe, yeah, the latter being more likely. You got it exactly reverse. const harms encapsulation because it exposes some details about implementations. It is often not applicable in sufficiently dynamic code. I don't see it that way. I find it very useful to know that an argument won't be modified. Example: suppose we have a large array (static array or wrapped in a struct) and need it as input for some independent operations. By knowing it won't be touched (passing by const ref) it is immediately clear that the operations can be run in parallel. Otherwise, one would need to go through the operations' implementation to determine if parallelization is possible. You do not see issues with changing the interface based on implementation details? I find it okay to require all possible changes to an argument passed by reference to be required to be directly visible by the caller, just to prevent accidentally missing side effects. Suppose a function takes a const reference parameter and is called at a site using an rvalue. After some time, that function is updated so that its parameter is or may be changed, changing the const ref parameter to a ref parameter. That may lead to big issues for the call sites. A compiler error would make sure the affected call sites are inspected and updated instead of potentially introducing regressions.
Re: [ ArgumentList ] vs. @( ArgumentList )
@(attribute) looks prettier to me, and with the other pros I think it's the clear winner. I always though C#'s [Attribute] syntax didn't make a lot of sense. I'm also for: @attr1 @attr2 int i; type syntax if that was being discussed previously (someone mentioned it). It would be very consistent with what's already there. Congrats on Attributes, BTW! Great news :)
Re: [ ArgumentList ] vs. @( ArgumentList )
Am 06.11.2012 20:18, schrieb Walter Bright: For User Defined Attributes. In the north corner we have the current champon: --- [ ArgumentList ] Pros: precedent with C# looks nice Cons: not so greppable parsing ambiguity with [array literal].func(); -- In the south corner, there's the challenger: @( ArgumentList ) Pros: looks like existing @attribute syntax no parsing problems Cons: not as nice looking -- No hitting below the belt! Let the games begin! Already too late to the party. I join my voice to the @() group. -- Paulo
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wednesday, 7 November 2012 at 16:55:23 UTC, Marco Leise wrote: Am Wed, 07 Nov 2012 09:19:41 +0100 schrieb "John Chapman" : > [ ArgumentList ] > > Pros: > precedent with C# And Delphi. That adds to the user base, but it is possible that in both cases Anders Hejlsberg was responsible for the design decision, making it more like a CDelphi# feature. :) Actually, C# got there first, Delphi not until 2010.
Re: [ ArgumentList ] vs. @( ArgumentList )
Am 06.11.2012 20:52, schrieb Manu: I'd like to re-enforce the consideration that @attribute() makes it looks like they affect the code generation somehow... they're really just annotations. On 6 November 2012 21:47, Jacob Carlborg mailto:d...@me.com>> wrote: On 2012-11-06 20:18, Walter Bright wrote: For User Defined Attributes. In the north corner we have the current champon: --- [ ArgumentList ] Pros: precedent with C# looks nice Cons: not so greppable parsing ambiguity with [array literal].func(); -- In the south corner, there's the challenger: @( ArgumentList ) Pros: looks like existing @attribute syntax no parsing problems Cons: not as nice looking -- No hitting below the belt! Let the games begin! I vote for @( ArgumentList ). If this is syntax chosen I also hope @attribute will be legal as well. -- /Jacob Carlborg Speaking from C# point of view, the same argument can be used, because in .NET [] attributes might change the way the code gets generated. Some of them like are even reckognized by the JIT/NGEN. -- Paulo
Re: Const ref and rvalues again...
On Wednesday, 7 November 2012 at 14:07:31 UTC, martin wrote:
C++:
void f(T& a) { // for lvalues
this->resource = a.resource;
a.resetResource();
}
void f(T&& a) { // for rvalues (moved)
this->resource = a.resource;
a.resetResource();
}
D:
void f(ref T a) { // for lvalues
this.resource = a.resource;
a.resetResource();
}
void f(T a) { // rvalue argument is not copied, but moved
this.resource = a.resource;
a.resetResource();
}
You could probably get away with a single-line overload, both in
C++ and D:
C++:
void f(T& a) { // for lvalues
// convert a to mutable rvalue reference and
// invoke the main overload f(T&&)
f(std::move(a));
}
D:
void f(T a) { // rvalue argument is not copied, but moved
// the original argument is now named a (an lvalue)
// invoke the main overload f(ref T)
f(a);
}
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wednesday, 7 November 2012 at 11:29:16 UTC, Simen Kjaeraas wrote: On 2012-12-07 11:11, Timon Gehr wrote: On 11/07/2012 09:28 AM, Simen Kjaeraas wrote: On 2012-19-07 09:11, John Chapman wrote: Personally, I also like . I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: bar)> This example does not show that they cause problems. Not true. The compiler certainly can handle it, but a programmer could easily be confused. I'm not putting it forward for consideration, but there is a precedent in Visual Basic - http://msdn.microsoft.com/en-US/library/h3z05kek%28v=vs.80%29.aspx
Re: [ ArgumentList ] vs. @( ArgumentList )
On 11/06/2012 08:18 PM, Walter Bright wrote: @( ArgumentList ) ... I do not like that one as I already use the syntax.
Re: Const ref and rvalues again...
On 11/07/2012 04:01 PM, martin wrote:
On Wednesday, 7 November 2012 at 10:33:03 UTC, Timon Gehr wrote:
You are still missing that const in C++ is different from const in D.
const in C++ does not mean anything. It is just loosely enforced
interface documentation. const in D actually restricts what the callee
can do with the argument, in a transitive fashion.
I still don't get the big difference (except for transitiveness for
pointers).
That is the main thing, but C++ also has a 'mutable' keyword.
Given a const reference, I'm only able to invoke methods
decorated with the const keyword (or inout in D) keyword, both in C++
and D. And I can only pass it as argument by ref to functions which do
not alter it (also taking a const reference, that is).
This is not the case in C++ for the D definition of 'not alter'.
Also, if the point is to have higher speed, why shouldn't the function
be allowed to use an rvalue as scratch space without a _deep copy_ ?
I'm sorry but I don't get what you mean here. Could you please elaborate
on this?
Well, if the changes are not visible, the function can freely change the
memory in order to perform its computations.
When my struct does not support any operations that are const, and
creating a mutable copy is not possible due to indirections?
If your struct doesn't support any const operations, it most likely has
good reasons not to.
Either that, or someone hasn't bothered to annotate.
The change may well be visible...
True in this case, but only if you know exactly what foo() does when you
call it inside the main() function. And that is probably an indicator
for bad encapsulation
The method is called 'foo', that means it is a toy example to show that
the change may be visible. The change does not necessarily have to be
visible to the caller directly.
- most of the time, you shouldn't have the
knowledge how foo() is exactly implemented when using it from the outside.
You got it exactly reverse. const harms encapsulation because it exposes
some details about implementations. It is often not applicable in
sufficiently dynamic code.
It is clear that there are some examples where you want to pass an
rvalue argument to a mutable ref parameter if you know exactly what the
function does. But imo these cases are very rare and I don't really
regard it as big issue if you need to add a line 'auto tmp = myRvalue;'
before the function call to transform it to a referenceable lvalue, in
these few cases.
You do not see issues with changing the interface based on
implementation details?
Much more commonly, you need a parameter just as read-only input.
Consider a real-word-example of a 4x4 matrix consisting of 16 doubles
(128 bytes). Most of the time, you'd only need a read-only input
instance when working with it (combining matrices, transforming vectors
etc.). Given its size (it's not really huge, I acknowledge that ;)), you
probably want to avoid copying it around and therefore pass it by ref,
but want that to also work for rvalues (produced by matrix combinations
like 'viewMatrix * modelMatrix', for example).
struct Matrix
{
double[16] data;
// this op= other
ref Matrix opOpAssign(string op)(in ref Matrix other);
// Matrix result = this op other
Matrix opBinary(string op)(in ref Matrix other) const;
// double4 result = this * vector
// the vector (32 bytes) may be passed by value for AVX
double4 opBinary(string op)(in ref double4 vector) const
if (op == "*");
};
I know your use case, and note that I do not have any issues with
rvalues always being allowed to bind to ref parameters, which would
solve your problem in all cases. (others do not like that though, which
is why we have the current situation and your C++ - inspired design is
discussed every second week or so.)
Re: [ ArgumentList ] vs. @( ArgumentList )
Am Wed, 07 Nov 2012 09:19:41 +0100 schrieb "John Chapman" : > > [ ArgumentList ] > > > > Pros: > > precedent with C# > > And Delphi. That adds to the user base, but it is possible that in both cases Anders Hejlsberg was responsible for the design decision, making it more like a CDelphi# feature. :) -- Marco
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wed, 07 Nov 2012 15:51:50 -, Nick Sabalausky wrote: On Tue, 06 Nov 2012 22:53:36 +0100 Artur Skawina wrote: "@[ArgumentList]". vote++ It has all the benefits of '@(...)' (which are very compelling on their own), but also has the *ONE* benefit of '[...]': Much less getting lost in stupid parenthesis, as demonstrated here: http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org I hadn't replied to this thread earlier because I didn't have a strong opinion either way, but, this suggestion appears to be the best of both worlds. So.. vote++ R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Mediawiki vs. Gollum vs ...
David Nadlinger wrote: > I still think Mediawiki is the better choice than Gollum if we > want a full-fledged wiki. As far as I can see it, a large part of > the dissatisfaction with the current wiki is precisely that it > doesn't support many of the convenient features people have come > to expect from modern wiki software. But Gollum seems to support > even less features than the prowiki.org software. Hi David, as I said, I don't have a strong opinion here. I'd add "watched pages" as a missing feature in Gollum. On the other hand I've not yet found a solution to clone the content of a Mediawiki instance for offline reading and backup. (I'd much appreciate hints!) The only show stopper of Mediawiki would be, if there was nobody to host and maintain it for D. Can you recommend a Mediawiki hosting service? I'm a contributor to several Mediawiki instances myself and even while I'm hating PHP with a passion I'd still consider it for non-technical topics. > For example, Andrej mentioned above how annoying it was that the > prowiki.org search doesn't work properly. Well, Gollum as running > on github.com doesn't seem to support search at all! I could live without search. If I need it, I use Google with the "site:" parameter to search only the wiki. > Or take user management: MediaWiki supports an extensive set of > tools for setting permission, banning users, protecting pages, > etc., which is proven to work in the real world. On the other > hand, I don't think that Gollum, due to its nature, supports any > kind of access control besides restricting wiki access to, in our > case, d-programming-language.org contributors. This is a problem > because an important part of the wiki concept is that everybody > can edit all/most of the pages, _without_ prior review. For this > to work, you also need to be able to take measures against > vandalism. There are two options: Only contributors can edit or everybody with a github account can edit. Only the latter makes sense for us. Public editing without a github account is not possile (AFAIK). The restriction to github accounts should provide sufficient protection against spam. Best regards, Thomas Koch
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wednesday, 7 November 2012 at 08:36:49 UTC, Jacob Carlborg wrote: On 2012-11-06 22:53, Walter Bright wrote: C++11 has had problems adding new keywords, as about every identifier somewhere has been used by someone's C++ source code, and they don't want to break existing code. So C++11 winds up with awful things like "decltype". Just create a new attribute, call it "builtin" or something similar, which takes attributes as arguments, i.e. @builtin(shared) int a; @builtin(property) int b; I'm not suggesting that we should change the existing @shared and @property, I just used them as an example. I honestly don't get why we keep reinventing the concept of namespaces. I agree with Jonathan regarding the identifier look-up rules in D. "std.algorithm.find" really should be *the default* unless the user specifically aliases that to "find" whereas now we have the exact opposite. But even without this we still should use D's already existing namespace solution - *the module system*. We should take a lesson from other platforms such as Java and .NET where everything is neatly organized. Let's stop this global identifiers nightmare! On that note, here's some things we *should not do*: - put unrelated random stuff in object.d - add more redundant ways to define namespaces such as __identifier, builtin(identifier), @attribute(identifier), @identifier, etc, etc.. - add more @keywords because they conflict with global identifiers. - have _huge_ single modules in Phobos that contain everything and ythe kitchen sink. I still hate with passion the "std.algorithm" "module". It's like opening a shop called "A Shop" or naming a newspaper "Newspaper". Proper organization is not inherently evil and we should not complicate the language design to compensate our current sloppiness.
Re: [ ArgumentList ] vs. @( ArgumentList )
On Tue, 06 Nov 2012 22:53:36 +0100 Artur Skawina wrote: > > "@[ArgumentList]". > vote++ It has all the benefits of '@(...)' (which are very compelling on their own), but also has the *ONE* benefit of '[...]': Much less getting lost in stupid parenthesis, as demonstrated here: http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wed, Nov 07, 2012 at 06:57:10AM +0100, Jakob Ovrum wrote: > On Wednesday, 7 November 2012 at 05:53:35 UTC, Jakob Ovrum wrote: > >I want to hear what people think about [] at declaration scope and > >@[] at statement scope. Too complicated to remember? Inconsistent. I don't like it. > This is quite bad for a variety of reasons, I'll change my vote for > purely having @[] then. I still prefer @(), for being easier to type on a variety of keyboards. T -- "Hi." "'Lo."
Re: deprecate deprecated?
On 2012-11-07 15:10, deadalnix wrote: Yes, but that should be the goal ! Absolutely. -- /Jacob Carlborg
Re: [ ArgumentList ] vs. @( ArgumentList )
On 2012-11-07 14:40, deadalnix wrote: I think D has already too many feature, and that many of them can be implemented as attribute + AST processing. D should work toward getting this AST stuff and stop adding new keywords all the time. I completely agree. -- /Jacob Carlborg
Re: Const ref and rvalues again...
On Wednesday, 7 November 2012 at 10:33:03 UTC, Timon Gehr wrote:
You are still missing that const in C++ is different from const
in D.
const in C++ does not mean anything. It is just loosely
enforced interface documentation. const in D actually restricts
what the callee can do with the argument, in a transitive
fashion.
I still don't get the big difference (except for transitiveness
for pointers). Given a const reference, I'm only able to invoke
methods decorated with the const keyword (or inout in D) keyword,
both in C++ and D. And I can only pass it as argument by ref to
functions which do not alter it (also taking a const reference,
that is).
Also, if the point is to have higher speed, why shouldn't the
function be allowed to use an rvalue as scratch space without a
_deep copy_ ?
I'm sorry but I don't get what you mean here. Could you please
elaborate on this?
When my struct does not support any operations that are const,
and creating a mutable copy is not possible due to indirections?
If your struct doesn't support any const operations, it most
likely has good reasons not to.
The change may well be visible...
True in this case, but only if you know exactly what foo() does
when you call it inside the main() function. And that is probably
an indicator for bad encapsulation - most of the time, you
shouldn't have the knowledge how foo() is exactly implemented
when using it from the outside.
It is clear that there are some examples where you want to pass
an rvalue argument to a mutable ref parameter if you know exactly
what the function does. But imo these cases are very rare and I
don't really regard it as big issue if you need to add a line
'auto tmp = myRvalue;' before the function call to transform it
to a referenceable lvalue, in these few cases.
Much more commonly, you need a parameter just as read-only input.
Consider a real-word-example of a 4x4 matrix consisting of 16
doubles (128 bytes). Most of the time, you'd only need a
read-only input instance when working with it (combining
matrices, transforming vectors etc.). Given its size (it's not
really huge, I acknowledge that ;)), you probably want to avoid
copying it around and therefore pass it by ref, but want that to
also work for rvalues (produced by matrix combinations like
'viewMatrix * modelMatrix', for example).
struct Matrix
{
double[16] data;
// this op= other
ref Matrix opOpAssign(string op)(in ref Matrix other);
// Matrix result = this op other
Matrix opBinary(string op)(in ref Matrix other) const;
// double4 result = this * vector
// the vector (32 bytes) may be passed by value for AVX
double4 opBinary(string op)(in ref double4 vector) const
if (op == "*");
};
Re: deprecate deprecated?
On Wednesday, 7 November 2012 at 13:43:39 UTC, Kagamin wrote: http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx http://msdn.microsoft.com/en-us/library/System.Diagnostics.ConditionalAttribute.aspx Oh, and C# has ObsoleteAttribute http://msdn.microsoft.com/en-us/library/System.ObsoleteAttribute.aspx
Re: [RFC] Add an operator for ranges to D. Pros and cons?
Dejan Lekic: Dear D community, I do not know about You, but I certainly do not like writing code like: inRange.fooRange(param).barRange. .bazRange(param1, param2).outRange; I suggest to format it this way, it's more readable: auto something = inRange .fooRange(param) .barRange() .bazRange(param1, param2) .outRange(); Therefore I would like to know what do you think about the idea of having additional operator exclusively made for ranges? This operator would make it obvious that data are "streamed" (lack of better term) among ranges. The first name I could come up with was "opArrow" but "opData" could also be okay, and operator would be either "~>" or "->". This would give us an obvious, unambiguous statement: Console.in ~> filter1(param) ~> fooRange ~> Console.out; // Console is an imaginary class/struct I think it doesn't give a significant improvement. But maybe there are more interesting use cases. I'd like D ranges to support the "~" (using a template mixin to give them such operator), that acts like chain. So instead of writing: range1.chain(range2) You write: range1 ~ range2 It's also nice to have lazy lists, maybe based on fibers, with few operators to concat them, etc. Bye, bearophile
Re: deprecate deprecated?
Le 07/11/2012 11:43, Jacob Carlborg a écrit : On 2012-11-07 00:56, Walter Bright wrote: I know there's been some long term unhappiness about the deprecated attribute - it's all-or-nothing approach, poor messages, etc. Each change in it changes the language and the compiler. Perhaps it could be done with a user defined attribute instead? Anyone want to take on the challenge? I think it's a bit too soon to start replacing language features with UDA. Yes, but that should be the goal !
Re: deprecate deprecated?
Le 07/11/2012 11:42, Jacob Carlborg a écrit :
On 2012-11-07 04:41, Walter Bright wrote:
It would be interesting to see where those pain points are, and whether
a general "hook" mechanism for user plugins would be a good idea.
I think that with UDA in combination with AST macros it could work.
@deprecated("don't use this feature any more") int foo (int a) { return
a + 3; }
In this case @deprecated would be a macro annotation/attribute or a
declaration macro or what to call it. The macro would receive the AST of
the declared language element, in this case the function. The AST return
by the macro would be inserted instead of the declared function "foo".
The @deprecated macro would return an AST for the following code:
int foo (int a)
{
static assert(false, "don't use this feature any more"); // use this for
error
// pragma(msg, "don't use this feature any more"); // use this for warning
return a + 3;
}
Have a look at Scala macro annotations:
http://scalamacros.org/future.html
This is nice, but lack the possible to explore the internal of the
function and to surgery in it :D
Still a step forward.
Re: Const ref and rvalues again...
On Wednesday, 7 November 2012 at 06:13:25 UTC, Rob T wrote:
ref T works fine, but if you wish to use f( ref T a ) on a temp
value returned from another function call, you'll need to
overload f() to pass by value, which means creating a duplicate.
Duplicating the function, yes, but not duplicating the rvalue
since it is moved in D. Isn't this analog to the C++ solution?
C++:
void f(T& a) { // for lvalues
this->resource = a.resource;
a.resetResource();
}
void f(T&& a) { // for rvalues (moved)
this->resource = a.resource;
a.resetResource();
}
D:
void f(ref T a) { // for lvalues
this.resource = a.resource;
a.resetResource();
}
void f(T a) { // rvalue argument is not copied, but moved
this.resource = a.resource;
a.resetResource();
}
T g() {
T temp;
temp.createResource();
return temp; // D already moves temp!
// 'Named Return Value Optimization'
}
I tried f( move(g()) ) but that fails to work. My best guess is
that D does a hidden move of the temp instead of a copy to
value. I can't say for sure because the documentation is not
clear and is missing important details like this. I also cannot
rely on clever compiler optimizations that may or may not be
implemented as a guarantee.
You could implement a copy constructor 'this(this)' in your
struct T and see when it is invoked to check when an instance is
actually copied. I'd expect that invoking 'f(g());' with above
implementation doesn't copy anything.
Re: a small study of "deprecate"
Here is how I see it (and all language fail at that as far as my knowledge goes). Deprecation comes with a date and a message. Before the date, the dev is presented with the deprecation message when compiling. The message explain why the function is deprecated and what to use instead. After the date, the message pops, but now it is an error (unless some flag is used). At some point the function may be removed.
Re: deprecate deprecated?
Le 07/11/2012 04:41, Walter Bright a écrit : On 11/6/2012 6:55 PM, Andrei Alexandrescu wrote: I don't think that's possible. One would need a mechanism to hook into all calls to a function (adorned with a specific attribute) and emit the message during compilation. That is missing. It would be interesting to see where those pain points are, and whether a general "hook" mechanism for user plugins would be a good idea. The hook should be in D and CTFEable. This require an API provided in druntime or phobos. This is heavy work, but would definitively worth it.
Re: [ ArgumentList ] vs. @( ArgumentList )
On 2012-11-07 14:36, deadalnix wrote: I think that was joke :D You never can be too certain when it comes to syntax suggestions :) -- /Jacob Carlborg
Re: [RFC] Add an operator for ranges to D. Pros and cons?
On Wednesday, 7 November 2012 at 13:07:13 UTC, Dejan Lekic wrote: I humbly believe that ranges are one of the most important concepts in D yeah, the range chaining is quite cool. I am just starting with D, and I find this formatting most appealing (took from a comment of an article about components). Console.in // get some input .filter1(param)// filter it based on X .fooRange // tweak it some more .Console.out; // beam it up, scotty It allows to describe the chaining inplace. You have though a point, if you are combining the ranges in a long 'sausage', a dedicated operator may increase the readability.
Re: std.signals2 proposal
On Tuesday, 6 November 2012 at 15:31:42 UTC, eskimo wrote: I've not read the code and I'm not 100% sure of the intentions of std.signal but why not just call the delegate as is? Signals are a way of a very loose coupling of components. This loose coupling is the reason why people usually expect weak reference semantics from signals. So people expect a signal connection to simply vanish when the observer object dies, instead of keeping it alive because it holds a reference to it. As long as you keep strong reference to the observer, it won't die. Having signals with weak reference semantics can be surprising for a garbage collected language: AFAIK Java and C# use strong reference semantics for observers. On the other hand one may want strong reference semantics: if you have e.g. a button.click listener, you don't want it to die prematurely, do you?
Re: Please enable wiki and issues at github
On Wednesday, 7 November 2012 at 07:45:19 UTC, Thomas Koch wrote: Do you agree? I still think Mediawiki is the better choice than Gollum if we want a full-fledged wiki. As far as I can see it, a large part of the dissatisfaction with the current wiki is precisely that it doesn't support many of the convenient features people have come to expect from modern wiki software. But Gollum seems to support even less features than the prowiki.org software. For example, Andrej mentioned above how annoying it was that the prowiki.org search doesn't work properly. Well, Gollum as running on github.com doesn't seem to support search at all! Or take user management: MediaWiki supports an extensive set of tools for setting permission, banning users, protecting pages, etc., which is proven to work in the real world. On the other hand, I don't think that Gollum, due to its nature, supports any kind of access control besides restricting wiki access to, in our case, d-programming-language.org contributors. This is a problem because an important part of the wiki concept is that everybody can edit all/most of the pages, _without_ prior review. For this to work, you also need to be able to take measures against vandalism. And for people just browsing the web for information about D, the fact that you can access the wiki pages as a Git repository with Gollum is simply not important at all (offline reading is also possible with MediaWiki, by the way, as commonly done with Wikipedia on mobile devices before the ubiquity of high-speed mobile internet connections). Well, it could quite possibly be that I am biased since I have a non-trivial number of contributions on two language editions of Wikipedia, but I still think that while the GitHub wiki is nice for having one or two pages of documentation with a few links for an open source project with zero effort, if we want a full-blown wiki for collecting and organization information about D, MediaWiki would be the best bet. It would certainly help to reduce the »awkwardness factor« of the current solution – after all, it is used by Wikipedia, many Linux distributions (Arch, Fedora, Gentoo, Suse, …), KDE, OpenOffice, and many other open source projects. Compared to it, most instances of other wiki systems almost invariably feel like a pile of mess to me. David
Re: a small study of "deprecate"
On Wed, 07 Nov 2012 13:16:26 -, monarch_dodra wrote: At this point, I have no solution to propose, but I think I have analyzed the root of the problem: "deprecate" is a two-phase function: "Fine, you can use me no problem whatsoever" to "too late, I'm deprecated! (or even gone)". The conclusion is that anything short of a "3-state solution" is bound to failure. We need a way to tell apart "2" from "3". Period. I'm not going to propose a solution in this post, but I think this is a good starting point for more discussion. Thoughts? I agree we want a 3 stage (at least) deprecation model. So the timeline would be.. 1. feature is usable (normal case) 2. feature is under deprecation "deprecate" (compiler issues a warning) 3. feature is "deprecated" (compiler issues an error) The warning in state 2 "deprecate" would point the user to the replacement feature. The error in state 3 "deprecated" would be a normal compiler error, but have an addition message to point the user to the replacement feature. In state 2 "deprecate" the code would be present, but annotated with "deprecate" to show that it was under deprecation. The compiler will still compile and use the code, but will issue the warning. In state 3 "deprecated" the code would no longer be present, instead a "deprecated" annotation would be present, giving the old feature name (symbol) and the additional message. The compiler will fail to compile - issuing the normal error for a missing symbol or what have you then output the deprecated annotation/message. This implies that for stage 3 the compiler has a symbol to deprecated message table which it searches on compile time errors (or similar). Is that the sort of behaviour we want? It could be more complicated, I'm sure, but this seems a nice and simple set of behaviour which would achieve the goal of allowing systematic deprecation. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [ ArgumentList ] vs. @( ArgumentList )
Le 07/11/2012 09:32, Nathan M. Swan a écrit : On 11/06/2012 10:18 AM, Walter Bright wrote: For User Defined Attributes. In the north corner we have the current champon: --- [ ArgumentList ] Pros: precedent with C# looks nice Cons: not so greppable parsing ambiguity with [array literal].func(); -- In the south corner, there's the challenger: @( ArgumentList ) Pros: looks like existing @attribute syntax no parsing problems Cons: not as nice looking -- No hitting below the belt! Let the games begin! [], because @ should be reserved for future language keywords. Whenever people post suggested language features that require some marking, they introduce a new @attribute, because introducing a plain keyword breaks code. If you have @UDAs, this further limits language expansion. Example: let's say you want to introduce a "nogc" mark: 1. Not a nogc keyword, that could break "bool nogc;" 2. If you have @, @nogc could break an "enum nogc;" attribute. 3. Now you're stuck with __nogc or #nogc or something uglier. There is a familiar-to-other-langauges advantage to @, but there is a better-than-other-languages advantage to []. My thoughts, NMS I think D has already too many feature, and that many of them can be implemented as attribute + AST processing. D should work toward getting this AST stuff and stop adding new keywords all the time.
Re: deprecate deprecated?
On Wednesday, 7 November 2012 at 02:55:38 UTC, Andrei Alexandrescu wrote: I don't think that's possible. One would need a mechanism to hook into all calls to a function (adorned with a specific attribute) and emit the message during compilation. That is missing. The attribute can be declared in library, but processed by the compiler - that's how C# works. See http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx http://msdn.microsoft.com/en-us/library/System.Diagnostics.ConditionalAttribute.aspx
