On Friday, 30 January 2015 at 09:21:17 UTC, Jacob Carlborg wrote:
On 2015-01-29 22:47, Walter Bright wrote:
Ruby also has monkey patching, another misfeature.
It works great, have you actually used it? The entire Rails
plugin system is built around monkey patching. It's far more
successful
On 1/30/2015 1:27 AM, Jacob Carlborg wrote:
In Ruby a newline works as a statement separator.
Making it not an example of what I was talking about.
On Friday, 30 January 2015 at 09:27:09 UTC, Jacob Carlborg wrote:
You need some kind of separation between the statements. In
Ruby a newline works as a statement separator.
I think Go actually injects ";" in the lexer on tokens that can
end statements if the token is followed by newline. Sound
On 2015-01-29 22:50, Walter Bright wrote:
"error message clarity, recovery, and the correct identification of the
location of the error degrades substantially"
I never had problems with the error messages in Ruby. But I do have had
problems with them in D. Example:
int a = 3
int b = 4;
T
On 2015-01-29 22:02, ketmar wrote:
this never worked good. see deadalnix. or:
foo.bar
.zed
In Ruby ".zed" is not valid code, so in Ruby it means:
foo.bar.zed;
In D it, with my rules, it would mean:
foo.bar;
.zed;
In D you would need to write:
foo.bar.
zed
--
/Jacob Carlborg
On 2015-01-29 22:47, Walter Bright wrote:
Ruby also has monkey patching, another misfeature.
It works great, have you actually used it? The entire Rails plugin
system is built around monkey patching. It's far more successful than
any D project.
--
/Jacob Carlborg
On Thursday, January 29, 2015 13:47:47 Walter Bright via Digitalmars-d wrote:
> Even so, lots of languages survive execrable features if they are
> counterbalanced by more desirable one.
C!
- Jonathan M Davis
On 1/29/2015 5:58 AM, Jacob Carlborg wrote:
On 2015-01-28 23:27, Walter Bright wrote:
For example, people often realize that the ; statement terminator is
redundant, so they propose removing it. In trying it, however, it soon
becomes clear that error message clarity, recovery, and the correct
i
On 1/29/2015 6:00 AM, Jacob Carlborg wrote:
On 2015-01-29 01:19, Walter Bright wrote:
One of the other mistakes they make is the great idea of implicit
declaration of variables, and then ruefully have to deprecate/remove it
a year or two later. (How could those experienced designers have missed
On Thursday, 29 January 2015 at 19:49:58 UTC, Jacob Carlborg
wrote:
On 2015-01-29 18:17, deadalnix wrote:
And it is so bad when the codebase grows that people are
willing
to switch to Node.js (!)
And still people are using it successfully.
Yes, my point is that there is tradeof.
This is e
On Thu, 29 Jan 2015 14:58:51 +0100, Jacob Carlborg wrote:
> On 2015-01-28 23:27, Walter Bright wrote:
>
>> For example, people often realize that the ; statement terminator is
>> redundant, so they propose removing it. In trying it, however, it soon
>> becomes clear that error message clarity, re
On Thu, 29 Jan 2015 17:17:44 +, deadalnix wrote:
> On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote:
>> On 2015-01-29 01:19, Walter Bright wrote:
>>
>>> One of the other mistakes they make is the great idea of implicit
>>> declaration of variables, and then ruefully have to d
On 2015-01-29 16:29, Kagamin wrote:
I suppose, when UDA conflicts with builtin attribute, that UDA can be
still disambiguated through module system.
We can always add another @ sign in front of new attributes ;)
--
/Jacob Carlborg
On 2015-01-29 18:17, deadalnix wrote:
And it is so bad when the codebase grows that people are willing
to switch to Node.js (!)
And still people are using it successfully.
--
/Jacob Carlborg
On Thursday, 29 January 2015 at 17:17:44 UTC, deadalnix wrote:
On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg
wrote:
On 2015-01-29 01:19, Walter Bright wrote:
One of the other mistakes they make is the great idea of
implicit
declaration of variables, and then ruefully have to
de
On Thursday, 29 January 2015 at 13:58:52 UTC, Jacob Carlborg
wrote:
A good language design that doesn't require the ; statement
terminator would recognize "void func()" as a valid statement
and implicit add ;. Scan the line, if a valid language
construct has been seen at the end of the line, in
On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg
wrote:
On 2015-01-29 01:19, Walter Bright wrote:
One of the other mistakes they make is the great idea of
implicit
declaration of variables, and then ruefully have to
deprecate/remove it
a year or two later. (How could those experien
On 28/01/2015 22:44, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
Could it be that new languages define grammars that are more robust than
the one used by C? Like Go?
We're not going to significantly change the structural syntax of D, so
it doesn't seem that your argument is particularly rel
On Wednesday, 28 January 2015 at 15:25:05 UTC, Dicebot wrote:
On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote:
Same goes for possible introduction of new attributes - if
syntax for those and UDA is identical, it can break code same
as introducing new keywords.
Same for any symbol
On 2015-01-28 20:07, Jonathan Marler wrote:
You seem to be defining a keyword in terms of an identifier that
is recognized by the compiler to have a special meaning.
By that definition basically all declarations in the object module is a
keyword :)
--
/Jacob Carlborg
On 2015-01-29 01:19, Walter Bright wrote:
One of the other mistakes they make is the great idea of implicit
declaration of variables, and then ruefully have to deprecate/remove it
a year or two later. (How could those experienced designers have missed
this obviously great feature?!?)
Ruby has
On 2015-01-28 23:27, Walter Bright wrote:
For example, people often realize that the ; statement terminator is
redundant, so they propose removing it. In trying it, however, it soon
becomes clear that error message clarity, recovery, and the correct
identification of the location of the error de
On Wednesday, 28 January 2015 at 22:44:45 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright
wrote:
For example, people often realize that the ; statement
terminator is redundant, so they propose removing it. In
trying it, however, it soon becomes clear
On Wednesday, 28 January 2015 at 19:33:32 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak
wrote:
I would think the reason would be it could make the grammar
ambiguous. That's why I proposed it only be valid on the
right hand side of the function to guara
On Thursday, 29 January 2015 at 10:50:49 UTC, ponce wrote:
In the Mythical Man Month, Brooks advises for a single person
responsible for architecture, or a dynamic duo (this is exactly
what we are with Walter and Andrei).
You mean like Batman?
I don't feel like discussing system development p
On Thursday, 29 January 2015 at 10:22:13 UTC, Ola Fosheim Grøstad
wrote:
Indeed, Walter has some deep reasoning ENTIRELY based on
personal experience. Unfortunately it totally lacks theoretical
backing and shows a complete disregard for how usability
evaluation is done.
Other popular langua
On Thursday, 29 January 2015 at 03:14:10 UTC, Zach the Mystic
wrote:
helped. I'm also glad Walter was able to follow it up with an
even better reasoning which speaks from deep experience, which
I could not have done. Let's move on!
Indeed, Walter has some deep reasoning ENTIRELY based on perso
On Thursday, 29 January 2015 at 00:03:52 UTC, Brian Schott wrote:
I take it you also don't care if your IDE lags for 5 seconds
every time you type a character?
Actually, modern parsers can parse ambiguous grammars in O(N)
using memoing.
Just because you are reluctant to implement a modern pa
On Thursday, 29 January 2015 at 02:23:56 UTC, Andrei Alexandrescu
wrote:
Nice. Interrogative - time to promote dscanner to tools/?
Brian, what do you think? -- Andrei
That discussion probably deserves its own thread.
On 1/28/15 4:29 PM, Brian Schott wrote:
I gave up on using dscanner and insisted on writing dscanner instead.
Nice. Interrogative - time to promote dscanner to tools/? Brian, what do
you think? -- Andrei
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic
wrote:
It's utterly confusing is the problem. I would consider it a
great disservice to all D programmers to allow this. Just
because you can doesn't mean you sho
On Thu, 29 Jan 2015 00:33:39 +, weaselcat wrote:
> Uncalled for IMO, Schott's tools are great.
sure. i wasn't talking about Brian in my text, that was my dumbiness that
paints the text personal.
signature.asc
Description: PGP signature
On Thu, 29 Jan 2015 00:29:26 +, Brian Schott wrote:
> On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:
>> that's good. as we already have at least 4 codebases to build tools
>> upon,
>> and you gave up using that and insisting on writing another one, and
>> failed... i doubt that yo
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:
On Thu, 29 Jan 2015 00:03:51 +, Brian Schott wrote:
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote:
I think a keyword is a keyword is a keyword. If it's a
k
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:
that's good. as we already have at least 4 codebases to build
tools upon,
and you gave up using that and insisting on writing another
one, and
failed... i doubt that your tool was really important or even
usable. so
now i don't have t
On 1/28/2015 3:14 PM, FG wrote:
On 2015-01-28 at 23:27, Walter Bright wrote:
Good language design has redundancy in it. Often people see the redundancy,
and advocate removing it as noise. But the redundancy has a valuable purpose -
diagnosing of errors, and offering suggestions for fixing the er
On Thu, 29 Jan 2015 00:03:51 +, Brian Schott wrote:
> On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
>> On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote:
>>
>>> I think a keyword is a keyword is a keyword. If it's a keyword to the
>>> right it should be one everywhere. H
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler
wrote:
Now if you can get that list of high priority issues out so I
can know what I should be working on that would be great!
It would be nice to know the priorities of the leadership, but,
if you have the skills to hack the com
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote:
I think a keyword is a keyword is a keyword. If it's a keyword
to the
right it should be one everywhere. How is somethign that's a
built-in
attribute one place and an identif
On Wed, 28 Jan 2015 23:36:29 +, deadalnix wrote:
> On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
>> On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote:
>>
>>> I think a keyword is a keyword is a keyword. If it's a keyword to the
>>> right it should be one everywhere. How
On 1/28/15 3:14 PM, FG wrote:
On 2015-01-28 at 23:27, Walter Bright wrote:
Good language design has redundancy in it. Often people see the
redundancy, and advocate removing it as noise. But the redundancy has
a valuable purpose - diagnosing of errors, and offering suggestions
for fixing the erro
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote:
I think a keyword is a keyword is a keyword. If it's a keyword
to the
right it should be one everywhere. How is somethign that's a
built-in
attribute one place and an identif
On Wed, 28 Jan 2015 22:39:01 +, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Grøstad
> wrote:
>> On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:
>>> Using "safe" as both a function attribute and an identifier doesn't
>>> seem confus
On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote:
> I think a keyword is a keyword is a keyword. If it's a keyword to the
> right it should be one everywhere. How is somethign that's a built-in
> attribute one place and an identifier in another not context sensitive.
yep. that is "slave
On 29/01/15 00:06, Dicebot via Digitalmars-d wrote:
I haven't said it is a breaking change on its own - but that doesn't mean it is
any considerably better migration-wise.
Yea, you're right, this isn't about whether the feature is good or not
(personally, I find Don's case for it persuasive) -
On 2015-01-28 at 23:27, Walter Bright wrote:
Good language design has redundancy in it. Often people see the redundancy, and
advocate removing it as noise. But the redundancy has a valuable purpose -
diagnosing of errors, and offering suggestions for fixing the errors. If there
was no redundan
On Wednesday, 28 January 2015 at 22:58:02 UTC, Joseph Rushton
Wakeling wrote:
On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:
However my complaint is not about the change itself (though I
personally
disagree with Don reasoning in that issue, it is a delicate
matter) but about
the fact that
On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:
However my complaint is not about the change itself (though I personally
disagree with Don reasoning in that issue, it is a delicate matter) but about
the fact that it is again done as a casual PR and our breaking change culture
does not seem to
On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright
wrote:
For example, people often realize that the ; statement
terminator is redundant, so they propose removing it. In trying
it, however, it soon becomes clear that error message clarity,
recovery, and the correct identification of t
On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler
wrote:
Using "safe" as both a function attribute and an identifier
doesn't seem confusing to me, however, it appears the
leadership agrees with you so I submi
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler
wrote:
Using "safe" as both a function attribute and an identifier
doesn't seem confusing to me, however, it appears the
leadership agrees with you so I submit.
Now you disappoint me. Your rebellious mindset has been poisoned
by t
On 1/28/2015 1:46 PM, Jonathan Marler wrote:
Your examples do bring up a usage I hadn't thought of though. It would be a bit
odd for newcomers to use "safe" without an '@' in one case and then have to
include the '@' another case (the example you provided). This makes it less
appealing. Either
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler
wrote:
Maybe this is a weak proposal but I don't know how to realize
that unless I ask the people who oppose it to explain
themselves.
How else will I learn?
I also think arguing is a very good way to learn too - but please
don'
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler
wrote:
Thanks Andrei, I appreciate your input on this. Now if you can
get that list of high priority issues out so I can know what I
should be working on that would be great!
+1.000.000.000
(Finally an empathic confession for bet
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic
wrote:
It's utterly confusing is the problem. I would consider it a
great disservice to all D programmers to allow this. Just
because you can doesn't mean you should. Walter has emphasize
there is absolutely no shortage of valid wor
On Wednesday, 28 January 2015 at 21:37:02 UTC, Daniel Kozak wrote:
Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v
19:33 +:
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak
wrote:
>> I would think the reason would be it could make the grammar
>> ambiguous. That's why
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic
wrote:
because you can doesn't mean you should. Walter has emphasize
there is absolutely no shortage of valid words.
@can @you @spot @the @contradiction @?
Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 19:33 +:
> On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
> >> I would think the reason would be it could make the grammar
> >> ambiguous. That's why I proposed it only be valid on the
> >> right hand side of the
On Wednesday, 28 January 2015 at 19:46:33 UTC, Andrei
Alexandrescu wrote:
I'd say we just drop it. It's a waste of time to talk about it.
There's no proof on why the idea isn't accepted, and there's no
need for one.
I just wrote out of empathy. As a newcomer to language
communities (including
On Wednesday, 28 January 2015 at 19:07:59 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic
wrote:
I think a keyword is a keyword is a keyword. If it's a keyword
to the right it should be one everywhere. How is somethign
that's a built-in attribute one p
On 1/28/15 11:13 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:
It may be the case you're using different definitions of the term
"contextual keyword". Far as I can tell you want the identifier "nogc"
be recognized in certain places by the co
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
I would think the reason would be it could make the grammar
ambiguous. That's why I proposed it only be valid on the
right hand side of the function to guarantee it doesn't
introduce any ambiguity. Other then that, I don't see
Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 19:13 +:
> On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei
> Alexandrescu wrote:
> > It may be the case you're using different definitions of the
> > term "contextual keyword". Far as I can tell you want the
> > identifier "nog
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic
wrote:
I think a keyword is a keyword is a keyword. If it's a keyword
to the right it should be one everywhere.
That's a reserved word. A reserved word cannot be used as an
identifier. A keyword is a phrase that has a special seman
On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei
Alexandrescu wrote:
It may be the case you're using different definitions of the
term "contextual keyword". Far as I can tell you want the
identifier "nogc" be recognized in certain places by the
compiler as special, and otherwise just not b
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic
wrote:
I think a keyword is a keyword is a keyword. If it's a keyword
to the right it should be one everywhere. How is somethign
that's a built-in attribute one place and an identifier in
another not context sensitive. Walter said t
On 1/28/15 10:59 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu
wrote:
That's not a misunderstanding. Your proposal has been understood. It
can be made to work. That doesn't necessarily make it desirable. I
don't think it's particularly helpful and
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei
Alexandrescu wrote:
That's not a misunderstanding. Your proposal has been
understood. It can be made to work. That doesn't necessarily
make it desirable. I don't think it's particularly helpful and
Walter is against it, so simply put it wo
On Wednesday, 28 January 2015 at 18:37:48 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei
Alexandrescu wrote:
On 1/28/15 10:19 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
On Wednesday, 28 January 2015 at 17:41:54 UTC, J
On 1/28/15 10:37 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:
On 1/28/15 10:19 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
P
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei
Alexandrescu wrote:
On 1/28/15 10:19 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan
Marler wrote:
PLUS, this would be very simple to implement!
On 1/28/15 10:19 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
PLUS, this would be very simple to implement!
Then I recommend you submit a pull request.
Mike
I would but Walter sa
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler
wrote:
PLUS, this would be very simple to implement!
Then I recommend you submit a pull request.
Mike
I would but Walter said no. I'm certain he misunderstood my
pro
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler
wrote:
PLUS, this would be very simple to implement!
Then I recommend you submit a pull request.
Mike
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler
wrote:
I have proposed a way that I think is a win win. Add support
for non-keyword function attributes on the right hand side of a
function signature. This will not break any code since it does
not require removing support for us
If we could start from scratch and guarantee that no new
attributes would
ever be introduced, then we could just put @ on none of them
and thus be
fully consistent. But we can't start from scratch, and we can't
guarantee
that there will be no new attributes. And even then, instead of
getting
co
On Monday, 26 January 2015 at 19:59:58 UTC, H. S. Teoh wrote:
On Mon, Jan 26, 2015 at 11:50:19AM -0800, Walter Bright via
Digitalmars-d wrote:
On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
>Personally, I'd much prefer that we not make this change.
It's good to have this discus
On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler
wrote:
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
3. Singularity of usage also matters. There should only be one
way to mark a given attribute, eith
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis
wrote:
On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:
We could also remove @ from all of the attributes, and then
that would be
"completely consistent," because then only UDAs will have @ on
them. But the
next ti
On Wednesday, 28 January 2015 at 16:39:51 UTC, Jonathan M Davis
wrote:
I don't see what any of that has to do with which attributes
have @ on them or not.
As I said, I misinterpreted what you wrote. You came through as
being overly defensive when it comes to accepting a syntax with
bad usabil
On Wednesday, January 28, 2015 16:10:28 via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis
> wrote:
> > inconsistencies and annoying points in the language. And much
> > of the time,
> > those inconsistencies and annoying points are forced by other
> > aspect
On 1/28/15 7:50 AM, Dicebot wrote:
On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei Alexandrescu wrote:
On 1/28/15 7:25 AM, Dicebot wrote:
The one who wants to make a change should propose a DIP. I am personally
OK with status quo for the time being - there are more important issues.
BTW
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis
wrote:
inconsistencies and annoying points in the language. And much
of the time,
those inconsistencies and annoying points are forced by other
aspects of the
language that actually make things nice and clean. There are
always
trad
On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei
Alexandrescu wrote:
On 1/28/15 7:25 AM, Dicebot wrote:
The one who wants to make a change should propose a DIP. I am
personally
OK with status quo for the time being - there are more
important issues.
BTW what's the deal with std.meta? --
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote:
Ya same thing applies to "body". I'm surprised no one has
given a reason why it wasn't done this way.
I made a PR, but it was not too well-received:
https://github.com/D-Programming-Language/dmd/pull/3227
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler
wrote:
Assuming I understand the problem, couldn't we modify the
language grammar to support more attributes without making
them keywords? Then we can omit the '@' on
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis
wrote:
On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:
On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis
wrote:
> consistent. They're
> always going to be inconsistent in one way or another, even
> if
On 1/28/15 7:25 AM, Dicebot wrote:
The one who wants to make a change should propose a DIP. I am personally
OK with status quo for the time being - there are more important issues.
BTW what's the deal with std.meta? -- Andrei
On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis
> wrote:
> > consistent. They're
> > always going to be inconsistent in one way or another, even if
> > it's simply
> > because they don't match what anyone coming from
On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote:
Same goes for possible introduction of new attributes - if
syntax for those and UDA is identical, it can break code same
as introducing new keywords.
Same for any symbol. Do you have a solution?
Long time ago I have proposed to ac
On Wednesday, 28 January 2015 at 14:41:09 UTC, Dicebot wrote:
And with no plans to deprecate old syntax even more
inconsistency had been introduced.
When the problem arises, then.
Same goes for possible introduction of new attributes - if
syntax for those and UDA is identical, it can break co
On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis
wrote:
consistent. They're
always going to be inconsistent in one way or another, even if
it's simply
because they don't match what anyone coming from other
languages expects
The logical conclusion from that statement would be th
On Wednesday, January 28, 2015 06:59:49 Andrei Alexandrescu via Digitalmars-d
wrote:
>
> Change has been reverted. -- Andrei
Yay!
- Jonathan M Davis
On Wednesday, January 28, 2015 14:41:08 Dicebot via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:
> > On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
> >> But in this case I see no improvement that could justify it.
> >
> > Fixes problems people
On Wednesday, 28 January 2015 at 14:59:48 UTC, Andrei
Alexandrescu wrote:
Change has been reverted. -- Andrei
Thank you very much.
Just to be perfectly clear : I am not against consolidating
attributes or even breaking things. Only thing I want is for such
changes to be done _simultaneously_
On 1/28/15 4:11 AM, Dicebot wrote:
On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote:
This change didn't break a single line in the libraries or the test
suite.
Yes, but it didn't also fix anything, only introduced more ways to do
the same thing - without any plans for some cons
On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:
On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
But in this case I see no improvement that could justify it.
Fixes problems people have with inconsistent attribute syntax,
see discussion at https://issues.dlang.org/sh
On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
But in this case I see no improvement that could justify it.
Fixes problems people have with inconsistent attribute syntax,
see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
On Wednesday, 28 January 2015 at 13:58:22 UTC, bearophile wrote:
The first one (the list comp) is Pythonic, and it's obviously
the obvious one :-)
If you want/need to use numpy, the fourth is good.
No problems :-)
Ok, so we agree, but I think the obvious way if we forget about
languages wou
On 28.01.15 14:14, bearophile wrote:
Dicebot:
Yes, but it didn't also fix anything, only introduced more ways to do
the same thing - without any plans for some consistent model.
One of the rules of the Python Zen:
There should be one-- and preferably only one --obvious way to do it.
Yes b
1 - 100 of 240 matches
Mail list logo
