On Tuesday, 26 January 2016 at 12:42:37 UTC, w0rp wrote:
I think we bicker and pontificate about these kinds of issues
too much.
Yes. Sorry, got carried away on a tangent.
Do we want @ for every attribute or not?
Yes.
If you worry about the compiler becoming too complicated, I can
On Monday, 25 January 2016 at 18:34:24 UTC, burjui wrote:
On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
If you need an IDE to work comfortably in a language,
something has clearly gone wrong.
Oh come on, not that "Vim/Emacs vs IDEs" crap again.
Not what he was saying at all. He
On Tuesday, 26 January 2016 at 13:16:10 UTC, Wyatt wrote:
On Tuesday, 26 January 2016 at 12:42:37 UTC, w0rp wrote:
Do we want @ for every attribute or not?
Yes.
I'll agree. A number of the attributes that use @ won't be an
option to use without the @; And having a half & half (or more
I think we bicker and pontificate about these kinds of issues too
much.
Do we want @ for every attribute or not? If we haven't decided,
we should decide.
If we do want @ for everything, then create a pull request which
does nothing but support @ for all current attributes, in
addition to
On Monday, 25 January 2016 at 18:34:24 UTC, burjui wrote:
On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
If you need an IDE to work comfortably in a language,
something has clearly gone wrong.
Oh come on, not that "Vim/Emacs vs IDEs" crap again. Please
stop being so black and
On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
If you need an IDE to work comfortably in a language, something
has clearly gone wrong.
Oh come on, not that "Vim/Emacs vs IDEs" crap again. Please stop
being so black and pretentious. Have you ever tried
IntelliJ IDEA? It's the best
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad
wrote:
[...]
I don't necessarily disagree with your overall point, but I
think the question of whether a few attributes have an @
attached to them or not ranks pretty
On Saturday, 23 January 2016 at 20:07:48 UTC, karabuta wrote:
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
I don't necessarily disagree with your overall point, but I
think the question of whether a few attributes have an @
attached to them or not ranks pretty low on the list
On Saturday, 23 January 2016 at 20:11:35 UTC, tsbockman wrote:
On Saturday, 23 January 2016 at 20:07:48 UTC, karabuta wrote:
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
I don't necessarily disagree with your overall point, but I
think the question of whether a few attributes
On Fri, Jan 22, 2016 at 06:08:14PM +, Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Friday, 22 January 2016 at 15:36:06 UTC, rsw0x wrote:
> >Maybe it's just me, but without my comfy braces I get lost. Large
> >python files feel like a maze to me honestly. Lispers might have
> >been onto
On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
I work with Python code without an IDE, and I manage just fine.
As long as you're consistent with how you use tabs vs. spaces,
it's not a problem. (Besides, even when it *is* a problem it's
not a *big* problem at all -- the
On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
If you need an IDE to work comfortably in a language, something
has clearly gone wrong.
In the case of Python what was wrong is that it accepts both tabs
and spaces for indentation. It should have required either tabs
or spaces. So you
On Friday, 22 January 2016 at 15:34:18 UTC, Wyatt wrote:
"Contemporary". ;)
Well, contemporary in the sense that next generation of
programmers are exposed to it and conditioned to it. So if you
pick up the common syntactical structures from those languages it
feels immediately natural to
On 2016-01-22 01:20, Era Scarecrow wrote:
If the fixes are easily automated requiring no intervention (other
than running a tool) then i would totally push for these changes;
Probably have a reminder notes during each release for people unaware of
dfix that it will fix these changes to source
On Friday, 22 January 2016 at 15:36:06 UTC, rsw0x wrote:
Maybe it's just me, but without my comfy braces I get lost.
Large python files feel like a maze to me honestly.
Lispers might have been onto something.
That's just conditioning. If you are used to "BEGIN" and "END"
picking up braces
On Friday, 22 January 2016 at 18:08:14 UTC, Ola Fosheim Grøstad
wrote:
That's just conditioning. If you are used to "BEGIN" and "END"
picking up braces takes time, same time the other way around.
BEGIN and END are still basically braces and they still serve in
the capacity of a visual anchor
On 2016-01-22 03:23, Dicebot wrote:
Putting built-in @-attributes in a runtime module publicly imported from
object.d is a very long proposal but last time it was discussed Walter
wasn't convinced it is of much gain AFAIR. May get there eventually, I
hope.
We at least have it for the
On Fri, Jan 22, 2016 at 06:39:39PM +, Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
> >If you need an IDE to work comfortably in a language, something has
> >clearly gone wrong.
>
> In the case of Python what was wrong is that it
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote:
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
Adding the @ to the old attributes was discussed as well, but
it didn't seem worth the code breakage.
I have to wonder if it would be that bad, since if you're
On Friday, 22 January 2016 at 00:24:13 UTC, Dibyendu Majumdar
wrote:
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
A revision of D that wasn't constrained by backwards
compatibility would almost certainly either require all
attributes to be prefixed by @, or change the grammar
On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
I work with Python code without an IDE, and I manage just fine.
As long as you're consistent with how you use tabs vs. spaces,
it's not a problem.
Yes, if you use the same editor and reformat source files you
download before
On Fri, Jan 22, 2016 at 10:11:45PM +, Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
> >I work with Python code without an IDE, and I manage just fine. As
> >long as you're consistent with how you use tabs vs. spaces, it's not
> >a
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
I don't necessarily disagree with your overall point, but I
think the question of whether a few attributes have an @
attached to them or not ranks pretty low on the list of "70%
solutions with marginal support" that need
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
Adding the @ to the old attributes was discussed as well, but
it didn't seem worth the code breakage.
And why not add the version of these attributes with @ and
deprecate these attributes without @ for some time? So it allow
On Friday, 22 January 2016 at 15:36:06 UTC, rsw0x wrote:
Maybe it's just me, but without my comfy braces I get lost.
Large python files feel like a maze to me honestly.
Lispers might have been onto something.
It's not just you; I completely agree. Python (and a lot of
ruby) is nearly
On Friday, 22 January 2016 at 09:46:47 UTC, Jonathan M Davis
wrote:
Not using @ on any attributes would be far cleaner, but it
would eat up more keywords, and we arguably have too many of
those already.
D is too complex to defend the position that you need _reserved_
keywords. Maybe at some
On Friday, 22 January 2016 at 08:23:48 UTC, Ola Fosheim Grøstad
wrote:
And, IMO, when redoing the syntax one might want to look at
contemporary languages like Swift and C# to see if one can
lower the barrier to entry for Apple and Microsoft type
programmers.
"Contemporary". ;) Aside from
On Friday, 22 January 2016 at 15:34:18 UTC, Wyatt wrote:
On Friday, 22 January 2016 at 08:23:48 UTC, Ola Fosheim Grøstad
wrote:
[...]
"Contemporary". ;) Aside from Swift's optional semicolons,
they're really not all that different.
[...]
Like Swift, C#, Javascript, Go, Haxe, Rust, Dart,
On Friday, 22 January 2016 at 13:30:40 UTC, Ola Fosheim Grøstad
wrote:
D is too complex to defend the position that you need
_reserved_ keywords. Maybe at some point in the past D1 was
simple enough to defend that position.
You write a parser once or twice, so having a clean syntax
weigh
On Fri, 22 Jan 2016 15:00:11 -0800, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jan 22, 2016 at 10:11:45PM +, Ola Fosheim Grøstad via
> Digitalmars-d wrote:
>> On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
>> >I work with Python code without an IDE, and I manage just fine.
On Thursday, 21 January 2016 at 23:48:03 UTC, Brian Schott wrote:
Yeah. Somebody should write something like that.
Wit. Hang on. *I* wrote something like that. The problem is
that nobody wants to make breaking changes even though dfix
exists.
https://github.com/Hackerpilot/dfix
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar
wrote:
I am puzzled as to why there is @nogc on the one hand and
simply nothrow on the other? Why are some attributes prefixed
with '@' while others aren't?
Regards
Short answer: It's for historical reasons; it would not be
On Thursday, 21 January 2016 at 23:14:14 UTC, Dibyendu Majumdar
wrote:
I see. And which approach is considered better? Personally
don't see why the '@' prefix is necessary.
Regards
Without the "@", the following valid code would break:
bool safe = !aIsDangerous && !bIsDangerous;
Every time
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote:
I have to wonder if it would be that bad, since if you're
aware of where it breaks (which source code) wouldn't a bulk
search/replace of the sources to resolve that?
It wouldn't be too bad, as such things go. But it also
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote:
Although I'll be honest, breaking code is never fun, and
making people scour their code to fix something that worked
before is just an annoyance. On the other hand I'm almost
tempted to suggest a tool that would update changes
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar
wrote:
I am puzzled as to why there is @nogc on the one hand and
simply nothrow on the other? Why are some attributes prefixed
with '@' while others aren't?
Regards
For historical reasons, basically. There have been some calls
I am puzzled as to why there is @nogc on the one hand and simply
nothrow on the other? Why are some attributes prefixed with '@'
while others aren't?
Regards
On Thursday, 21 January 2016 at 23:58:31 UTC, jmh530 wrote:
Perhaps they could begin a process, like adding @pure and
@nothrow. Then, people at least people can update source code
at their own pace. I doubt adding those would break much code
(which makes me wonder if it would be possible to do
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
Adding the @ to the old attributes was discussed as well, but
it didn't seem worth the code breakage.
I have to wonder if it would be that bad, since if you're aware
of where it breaks (which source code) wouldn't a bulk
On Thursday, 21 January 2016 at 23:08:07 UTC, Brad Anderson wrote:
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar
wrote:
I am puzzled as to why there is @nogc on the one hand and
simply nothrow on the other? Why are some attributes prefixed
with '@' while others aren't?
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
A revision of D that wasn't constrained by backwards
compatibility would almost certainly either require all
attributes to be prefixed by @, or change the grammar such that
attribute names could be reused as identifier names
On Thursday, 21 January 2016 at 23:48:03 UTC, Brian Schott wrote:
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow
wrote:
I'm almost tempted to suggest a tool that would update changes
to source code when some of these things happen, dealing with
most of these types of problems.
On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 21 January 2016 at 23:48:14 UTC, tsbockman wrote:
It wouldn't be too bad, as such things go. But it also serves
little practical purpose; why break people's code for purely
aesthetic reasons?
1. Because it
On 01/22/2016 03:20 AM, Dicebot wrote:
I'd definitely place something like `@safe` in type constructors
@safe(int) ?
On Friday, 22 January 2016 at 00:11:02 UTC, Brian Schott wrote:
I wrote up the details of this idea as a DIP many months ago:
http://wiki.dlang.org/DIP64
It's already implemented in dfix. You can run "dfix --dip64
file.d" and the changes will be made automatically.
The problem with DIP64
On Friday, 22 January 2016 at 02:12:27 UTC, Adam D. Ruppe wrote:
Well, technically, since UDAs exist, every new @thing is
potential breakage too, though of course, limited in scope.
(If I was doing it, I'd actually make the ones be implicitly
imported names, so you could disambiguate with teh
On Friday, 22 January 2016 at 03:18:29 UTC, Timon Gehr wrote:
On 01/22/2016 03:20 AM, Dicebot wrote:
I'd definitely place something like `@safe` in type
constructors
@safe(int) ?
Normally I rely on this definition:
feature .. builds new types from old ones
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar
wrote:
I am puzzled as to why there is @nogc on the one hand and
simply nothrow on the other? Why are some attributes prefixed
with '@' while others aren't?
Regards
"breakage" that could be fixed in a few minutes with grep
On Thursday, 21 January 2016 at 23:19:19 UTC, Brian Schott wrote:
Every time a new keyword is added to the language some working
code will become invalid.
Well, technically, since UDAs exist, every new @thing is
potential breakage too, though of course, limited in scope.
(If I was doing it,
On Thursday, 21 January 2016 at 23:48:14 UTC, tsbockman wrote:
It wouldn't be too bad, as such things go. But it also serves
little practical purpose; why break people's code for purely
aesthetic reasons?
1. Because it isn't purely aesthetic, it is also a question of
usability.
2. Because
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad
wrote:
[...]
I don't necessarily disagree with your overall point, but I
think the question of whether a few attributes have an @
attached to them or not ranks pretty
51 matches
Mail list logo
