[Issue 24376] New: ImportC: .di generator outputs D keywords for members

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=24376

  Issue ID: 24376
   Summary: ImportC: .di generator outputs D keywords for members
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ImportC
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dave287...@gmail.com

This is already noted as a limitation of ImportC (the mismatch in keywords) and
in D code you can work around it using __traits. However, in the .di generator
you instead get a parse error:

C code:

struct foo {
int version;
const char* function;
int uint;
};

.di file:

// ...
struct foo
{
int version = void;
const(char)* function = void;
int uint = void;
}
// ...

Trying to import the .di file will then fail.

I think ideally you solve this with adding a mechanism for D identifiers to
have the same name as keywords. A new kind of string?

Another way to go is to have the compiler rename identifiers that are D
keywords when importing C code (say by appending an underscore). Could also
only do that in the .di generation, but then importing the C code and importing
the .di file are different.

--

[Issue 24312] importC: Document workaround for using C symbols which are also D keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=24312

Dennis  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dkor...@live.nl
 Resolution|--- |FIXED

--- Comment #3 from Dennis  ---
Fixed by https://github.com/dlang/dlang.org/pull/3752

--

[Issue 24312] importC: Document workaround for using C symbols which are also D keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=24312

Walter Bright  changed:

   What|Removed |Added

   Keywords||ImportC, spec
  Component|dmd |dlang.org

--

[Issue 24312] importC: Document workaround for using C symbols which are also D keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=24312

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@WalterBright created dlang/dlang.org pull request #3752 "fix Issue 24312 -
importC: Document workaround for using C symbols wh…" fixing this issue:

- fix Issue 24312 - importC: Document workaround for using C symbols which are
also D keywords

https://github.com/dlang/dlang.org/pull/3752

--

[Issue 24312] importC: Document workaround for using C symbols which are also D keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=24312

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
good idea

--

[Issue 24312] New: importC: Document workaround for using C symbols which are also D keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=24312

  Issue ID: 24312
   Summary: importC: Document workaround for using C symbols which
are also D keywords
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: andrej.mitrov...@gmail.com

I might make a PR for this later, but I'm keeping this as a placeholder. 

Initially this was going to be a bug report but I found a neat workaround.

This is similar to https://issues.dlang.org/show_bug.cgi?id=23004, except it's
about calling C code on the D side.

clap.c:
-
typedef struct clap_host {
   const char *version;
} clap_host_t;

typedef struct clap_plugin_entry {
void (*init)(const char *plugin_path);
} clap_plugin_entry_t;
-

And two separate test-cases. They're separate because the error in the first
test-case makes the second test-case error disappear (short-circuit of errors I
guess):

test1.d: 
-
import clap;

void main() {
clap_host* host;
host.version = null;
}
-

test2.d: 
-
import clap;

void main() {
clap_plugin_entry* entry;
entry.init(null);
}
-

```
$ dmd -c test1.d clap.c
test1.d(5): Error: identifier or `new` expected following `.`, not `version`

$ dmd -c test2.d clap.c
test.d(5): Error: function expected before `()`, not `null` of type
`clap_plugin_entry*
```

I understand this can't be allowed since it's semantically invalid D code.

There is however a workaround using the getMember trait:

```
import clap;

void main() {
clap_plugin_entry* entry;
__traits(getMember, *entry, "init")(null);

clap_host* host;
__traits(getMember, *host, "version") = null;
}
```

I think it would be good to document this workaround on the ImportC page:
https://dlang.org/spec/importc.html

--

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 19988] Provide a way to use dlang reserved keywords in certain circumstances

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19988

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 12986] keywords allowed in module names if no ModuleDeclaration is used

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12986

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #1 from RazvanN  ---
Yes, the problem is that the parser expects an identifier not a keyword after
the the `module` token. This is a minor limitation and as Walter has pointed
out:

"I think that 'fixing' this is probably more trouble than its worth. While such
modules do work for internal modules that have no D interface, they won't work
anyway for regular D modules, and the user will find that out pretty quick."

Closing as WONTFIX.

--

[Issue 166] Proposed new Bugzilla keywords: undefined, warning

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=166

--- Comment #3 from Dlang Bot  ---
dlang/dlang-bot pull request #271 "Fixes so far" was merged into master:

- e4775e9412f288818d94efe5f7a9f3baf4f8e3a3 by Vladimir Panteleev:
  Cache GitHub API requests

  Cache hits do not count against the API rate-limit, so it is always
  beneficial to do so.

  The caching code is reused from
  https://github.com/CyberShadow/DAutoTest/blob/master/github.d and
  https://github.com/CyberShadow/ae/blob/next/net/github/rest.d, though
  it omits the redirect handling code (which is also added in the
  following commit).

  Fixes #166.

https://github.com/dlang/dlang-bot/pull/271

--

[Issue 21530] dtoh: Identifiers need to be sanitized wrt. reserved C++ keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21530

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/dmd pull request #12122 "Fix 21530 - dtoh: Sanitize identifiers wrt.
reserved C++ keywords" was merged into master:

- 843bc8549e264b9a4b127a6da8f98524d52f23b1 by MoonlightSentinel:
  Fix 21530 - dtoh: Sanitize identifiers wrt. reserved C++ keywords

  Extends the check for C++ keywords to append an underscore instead of
  raising an error whenever the actual name doesn't matter for binary
  compatibility.

https://github.com/dlang/dmd/pull/12122

--

[Issue 21530] dtoh: Identifiers need to be sanitized wrt. reserved C++ keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21530

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@MoonlightSentinel created dlang/dmd pull request #12122 "Fix 21530 - dtoh:
Sanitize identifiers wrt. reserved C++ keywords" fixing this issue:

- Fix 21530 - dtoh: Sanitize identifiers wrt. reserved C++ keywords

  Extends the check for C++ keywords to append an underscore instead of
  raising an error whenever the actual name doesn't matter for binary
  compatibility.

https://github.com/dlang/dmd/pull/12122

--

[Issue 21530] New: dtoh: Identifiers need to be sanitized wrt. reserved C++ keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21530

  Issue ID: 21530
   Summary: dtoh: Identifiers need to be sanitized wrt. reserved
C++ keywords
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ki...@gmx.net

E.g., from frontend.h:

enum class PASS
{
inline = 7 // needs to be sanitized to `inline_` or so
};

See https://en.cppreference.com/w/cpp/keyword.

--

[Issue 5881] Spellchecker should include built-in keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5881

Basile-z  changed:

   What|Removed |Added

 CC|b2.t...@gmx.com |

--

[Issue 5881] Spellchecker should include built-in keywords

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5881

Basile-z  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |WONTFIX

--- Comment #4 from Basile-z  ---
that's not a good idea. The spell checker is a help to fix typo in
**identifiers** so if you add keyword proposal people will end up being
proposed to use a keyword that would not work !


there is only `pragma` and `assert` BTW who have a CallExp like syntax.

--

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

Mathias LANG  changed:

   What|Removed |Added

 CC||pro.mathias.l...@gmail.com

--- Comment #3 from Mathias LANG  ---
For C `pragma(mangle)` is an easy workaround, however for `extern(C++)`, not
only is the mangling non-trivial, but it's currently impossible to do for
anything templated, since the mangling depend on template parameters which are
not available to `pragma(mangle)`.

--

[Issue 19988] New: Provide a way to use dlang reserved keywords in certain circumstances

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19988

  Issue ID: 19988
   Summary: Provide a way to use dlang reserved keywords in
certain circumstances
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: vaidas.bo...@gmail.com

Related d lang forum's thread:
https://forum.dlang.org/post/tzqpyibkquexlyzsb...@forum.dlang.org

--

[Issue 17528] dlangspec.pdf: keywords and globally defined symbols tables have broken formatting

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17528

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |FIXED

--- Comment #2 from Andrei Alexandrescu  ---
These issues seem to be fixed by the recent PRs.

--

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

--- Comment #2 from Vladimir Panteleev  ---
In this particular case, the easiest workaround is to use pragma(mangle),
right?

I understand that this is more useful for C++ functions, whose mangling is
non-trivial.

--

[Issue 17528] dlangspec.pdf: keywords and globally defined symbols tables have broken formatting

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17528

--- Comment #1 from greensunn...@gmail.com ---
The same happens for storage classes: http://imgur.com/GfB3VrP

--

[Issue 17528] New: dlangspec.pdf: keywords and globally defined symbols tables have broken formatting

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17528

  Issue ID: 17528
   Summary: dlangspec.pdf: keywords and globally defined symbols
tables have broken formatting
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

The arrows looks really weird:

http://imgur.com/7h1b0ey
http://imgur.com/HLt730e

And they still don't help:

http://imgur.com/WWU5HM9

--

[Issue 5984] add new keywords objconst and objimmutable to make it possible to declare mutable reference variables referencing const or immutable class instances

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5984

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |WONTFIX

--

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

--- Comment #1 from Sobirari Muhomori  ---
Another option:
extern (C++) int __symbol__with();
And let C++ mangler recognize and remove the __symbol__ prefix.

Choose your naming convention:
alias with_ = __symbol__with;
alias _with = __symbol__with;
alias _with_ = __symbol__with;
alias With = __symbol__with;

--

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

Walter Bright <bugzi...@digitalmars.com> changed:

   What|Removed |Added

   Keywords||C++

--

[Issue 15587] New: Enable use of D keywords as identifiers when interfacing to C/C++

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15587

  Issue ID: 15587
   Summary: Enable use of D keywords as identifiers when
interfacing to C/C++
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Consider:

extern (C) int* with();

where delegate is a C function name. This, of course, fails because 'with' is a
D keyword. A solution is:

extern (C) int* with_();

and have the C/C++ name mangler remove any trailing _ from identifiers.

The prefix version, _with, has problems because it would be impossible to have
a C identifier named '_traits' or '_gshared'.

--

[Issue 910] Error in description of this and super keywords

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=910

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 166] Proposed new Bugzilla keywords: undefined, warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=166

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 1505] keywords list needs some work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1505

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

  Component|general |websites
Product|puremagic.com   |D

--

[Issue 1505] keywords list needs some work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1505

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 166] Proposed new Bugzilla keywords: undefined, warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=166

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

  Component|general |websites
Product|puremagic.com   |D

--

[Issue 1267] crash-on-valid-code and crash-on-invalid-code keywords?

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1267

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 9469] Keywords list could use linkage; more-humane documentation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9469

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||hst...@quickfur.ath.cx
 Resolution|--- |FIXED

--- Comment #2 from hst...@quickfur.ath.cx ---
PR has been merged a long time ago, seems to be fixed now.

--

[Issue 12986] New: keywords allowed in module names if no ModuleDeclaration is used

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12986

  Issue ID: 12986
   Summary: keywords allowed in module names if no
ModuleDeclaration is used
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: sigod.m...@gmail.com

Related to: https://issues.dlang.org/show_bug.cgi?id=456
I opened new issue because old one was about D1.

I suggest that:
1. Or keywords must be disallowed for module names completely.
2. Or documentation must be modified to explain hidden feature. Actually
currently it speaks only about package names.

In issue 456 was said that this change will break some of phobos' modules. Now
as I see it will only break `unittest.d`.

--

[Issue 5881] Spellchecker should include built-in keywords

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=5881


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 CC||yebbl...@gmail.com


--- Comment #2 from yebblies yebbl...@gmail.com 2014-03-21 23:02:06 EST ---
(In reply to comment #1)
 Everyone: is there a singular list of all the keywords somewhere?

Inside the compiler or one of the alternative lexers.

I think this is of questionable value - basic syntax highlighting makes this
unnecessary.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5881] Spellchecker should include built-in keywords

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=5881


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #3 from bearophile_h...@eml.cc 2014-03-21 05:33:08 PDT ---
(In reply to comment #2)

 I think this is of questionable value

See also Issue 6946

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5881] Spellchecker should include built-in keywords

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=5881


Infiltrator lt.infiltra...@gmail.com changed:

   What|Removed |Added

 CC||lt.infiltra...@gmail.com


--- Comment #1 from Infiltrator lt.infiltra...@gmail.com 2014-03-19 17:43:00 
PDT ---
Everyone: is there a singular list of all the keywords somewhere?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10522] __FILE__ and other special keywords cannot be used with printf

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10522


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||yebbl...@gmail.com
 Resolution||INVALID


--- Comment #1 from yebblies yebbl...@gmail.com 2013-08-20 00:38:30 EST ---
Neither can string literals!  printf is a c-varargs function, and has no way of
knowing you want the implicit conversion to const(char)*.

Solutions:
printf(-- %s\n, cast(const(char*))__FILE__);
printf(-- %.*s\n, __FILE__.length, __FILE__.ptr);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10522] __FILE__ and other special keywords cannot be used with printf

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10522



--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-19 
08:35:40 PDT ---
(In reply to comment #1)
 Neither can string literals!  printf is a c-varargs function, and has no way 
 of
 knowing you want the implicit conversion to const(char)*.

I guess that shows how spoiled I am by D's variadic templates. :)

 printf(-- %s\n, cast(const(char*))__FILE__);

Also __FILE__.ptr and __FILE__.toStringz.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10522] New: __FILE__ and other special keywords cannot be used with printf

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10522

   Summary: __FILE__ and other special keywords cannot be used
with printf
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com


--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-07-01 
15:00:08 PDT ---
-
import std.stdio;

void main()
{
printf(-- %s\n, __FILE__);
printf(-- %s\n, __FUNCTION__);
printf(-- %s\n, __PRETTY_FUNCTION__);
}
-

 object.Error: Access Violation

The use-case are printf statements in destructors, which unlike writef will
avoid any allocations (which typically fail in dtors due to the GC being
stopped).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9469] Keywords list could use linkage; more-humane documentation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9469


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2013-02-10 19:00:10 
CET ---
https://github.com/D-Programming-Language/d-programming-language.org/pull/266

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9440] Listing of keywords on dlang.org does not match compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9440


hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx


--- Comment #1 from hst...@quickfur.ath.cx 2013-02-09 08:05:09 PST ---
IIRC, the spec does say that all identifiers that begin with __ are reserved
for internal compiler use.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9440] Listing of keywords on dlang.org does not match compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9440


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||WONTFIX


--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-09 
08:09:57 PST ---
There was a pull for this which was rejected because these are internal. Also
__thread is being removed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9469] New: Keywords list could use linkage; more-humane documentation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9469

   Summary: Keywords list could use linkage; more-humane
documentation
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: websites
AssignedTo: nob...@puremagic.com
ReportedBy: wyatt@gmail.com


--- Comment #0 from Wyatt wyatt@gmail.com 2013-02-07 03:34:38 PST ---
The list at http://dlang.org/lex.html#Keyword is long and flat. It would be
well-served by linking to relevant documentation entries for each keyword in
cases where that exists. (Things like interface, mixin, pragma, scope, et al). 
The goal is to make navigating the documentation less error-prone for
newcomers.

As an additional consideration, it would be nice if each item in that list had
(at least) a short, single sentence, description.  Keywords with zero context
often fail to indicate what they interact with, which impedes language
acquisition. (e.g. it simplifies questions like What does 'synchronized' even
do?).

To some extent, I feel the keywords deserve their own page. (In-addition-to if
not instead-of a flat list on the lexical page.)  Simply finding the list is
more difficult than it needs to be, as there are no top-level anchors for the
Lexical page and the keyword anchor is simply mixed in with the list of tokens.
 Going this direction, it would probably be helpful to also arrange them
according to their documentation section for reinforcement.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9440] New: Listing of keywords on dlang.org does not match compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9440

   Summary: Listing of keywords on dlang.org does not match
compiler
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: websites
AssignedTo: nob...@puremagic.com
ReportedBy: brian-sch...@cox.net


--- Comment #0 from brian-sch...@cox.net 2013-02-01 14:17:29 PST ---
The lexical standard for D posted at http://dlang.org/lex.html currently lacks
the following keywords present in dmd:
__thread
__overloadset
__argTypes

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5984] add new keywords obj_const and obj_immutable to make it possible to declare mutable reference variables referencing const or immutable class instances

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5984



--- Comment #2 from Christopher the Magnificent ultimatemacfana...@gmail.com 
2011-05-13 10:09:30 PDT ---
Where do I find the const(Object) ref syntax described?  I've never run
across it in the D Language Reference.  Point me to some info about this
particular syntax and then I'll be able to comment on how my own syntax may be
superior.

(In reply to comment #1)
 How is this better than the 'const(Object) ref' syntax*?
 
 class A { ... }
 
 immutable(A) func(immutable A a1, immutable A a2) {
 immutable(A) ref a_ptr = null;
 ...
 }
 
 and
 
 const(ClassName)ref[] myArray;
 
 Actually there is already std.typecons.Rebindable which mostly works (uglily):
 
 class A { ... }
 
 immutable(A) func(immutable A a1, immutable A a2) {
 Rebindable!(immutable(A)) a_ptr = null;
 ...
 }
 
 and
 
 Rebindable!(const(ClassName))[] myArray;
 myArray.length = 1;
 myArray[0] = constant_object;
 myArray ~= rebindable(constant_object);
 
 *: https://github.com/D-Programming-Language/dmd/pull/3

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5984] add new keywords obj_const and obj_immutable to make it possible to declare mutable reference variables referencing const or immutable class instances

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5984



--- Comment #3 from kenn...@gmail.com 2011-05-13 11:43:14 PDT ---
(In reply to comment #2)
 Where do I find the const(Object) ref syntax described?  I've never run
 across it in the D Language Reference.  Point me to some info about this
 particular syntax and then I'll be able to comment on how my own syntax may be
 superior.
 

This is a third-party proposal, and isn't even approved. You won't find it in
the official reference ;)

See bug 5325 and the huge thread in
http://www.digitalmars.com/d/archives/digitalmars/D/const_Object_ref_is_here_123681.html.
You may also search for tail const to find a lot of previous discussions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5984] add new keywords obj_const and obj_immutable to make it possible to declare mutable reference variables referencing const or immutable class instances

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5984



--- Comment #4 from Christopher the Magnificent ultimatemacfana...@gmail.com 
2011-05-13 15:29:16 PDT ---
Okay, thanks for bringing me up to speed with the existing const(Object) ref
stuff.

Here's my thought.  The const(Object) ref syntax, while getting the job done,
is undesirable because it highjacks an existing syntax in such a way that
previous meaning of what is being added to is lost.

Here's what I mean.

const(MyObject)   myVar;

In the above thing, const(Object) is the type, and it means a constant
variable referencing a constant object of class MyObject.

Now we have

const(MyObject) refmyVar2;

Is myVar2 a reference to an entity of type const(MyObject)?  In other words,
is myVar a *reference to a constant variable referencing to a constant object
of class MyObject*?

Nope!  But I submit that that's exactly what this syntax suggests to a person
of average intuition.

This ref syntax implies two levels of pointers as in a ref to a const ref to
a const object.  This is not what the syntax actually does.  When you have the
ref after it then the const(MyObject) part suddenly stops meaning constant
variable referencing constant object and starts meaning constant object.
Therefore, the syntax is to me misleading and liable to be misunderstood.  

Second, in the mailing list I read someone wanting to do this:

MyObject refmyVar;  // ref keyword ensures that MyObject is a
class; error if MyObject is a struct

This seems to encourage people to indiscriminately insert keyword ref and
litter their D code with syntactic fluff that, while providing a sanity check,
doesn't actually change the meaning of correctly written code, making stuff
harder to read, and all this rather than requiring people to just look up the
interface and double check that something is indeed a class before they start
to use it.

There may be a benefit to instituting a compiler check that asserts something
is a struct vs. a class, but I don't think using the keyword ref is the best
way to do this.  I have my own idea about this--just permit the optional
prefixing of the type names with class, struct, or enum and the compiler
doubles checks it.  This is a better solution because those three keywords
reinforce what they're doing, rather than restating the obvious (that the
variable is storing a reference).

Now look at my syntax:

// the following two are equivalent
objconst MyObject   myVar;

const(objimmutable(MyObject))*  myPtr;  // pointer to const variable
referencing immutable object

objconst(MyObject)[]  myArray;   // array of mutable variables
referencing const objects

ADVANTAGES:
* This syntax is visually cleaner
* Parentheses may be omitted for the simple case above--not so with
const(MyObject) ref
* Requires only one keyword instead of two.
* It doesn't appear to change the meaning of existing syntax like
const(MyObject) ref does
* When the syntax is used, it always has an effect upon the meaning of the
program.  Does not turn into fluff.
* It is more specific in its usage and it its effect than the alternative.
* It solves a single problem well, rather than trying to do several things at
once in an obscure fashion.

BY THE WAY
I think I like the variety of keywords without the underscores best.  Do you
like my keywords better with or without underscores?



(In reply to comment #3)
 (In reply to comment #2)
  Where do I find the const(Object) ref syntax described?  I've never run
  across it in the D Language Reference.  Point me to some info about this
  particular syntax and then I'll be able to comment on how my own syntax may 
  be
  superior.
  
 
 This is a third-party proposal, and isn't even approved. You won't find it in
 the official reference ;)
 
 See bug 5325 and the huge thread in
 http://www.digitalmars.com/d/archives/digitalmars/D/const_Object_ref_is_here_123681.html.
 You may also search for tail const to find a lot of previous discussions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5984] New: add new keywords obj_const and obj_immutable to make it possible to declare mutable reference variables referencing const or immutable class instances

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5984

   Summary: add new keywords obj_const and obj_immutable to make
it possible to declare mutable reference variables
referencing const or immutable class instances
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ultimatemacfana...@gmail.com


--- Comment #0 from Christopher the Magnificent ultimatemacfana...@gmail.com 
2011-05-11 13:08:28 PDT ---
Suppose we have struct A:

struct A
{
...
}


Next, suppose we have a function that takes two immutable pointers to As
(plural of A) 

immutable(A)*
func(immutable A* a1, immutable A* a2)
{
...
}


Finally suppose that we need a variable that can alternately point to the
object pointed to by a1 or a2 (which and be changed later during the function. 
This is straightforward in D.  It looks like this:



immutable(A)*
func(immutable A* a1, immutable A* a2)
{
//TAKE NOTE OF THIS LINE--DECLARES MUTABLE POINTER TO IMMUTABLE STRUCT
OBJECT
immutable(A)* a_ptr = null; 

a_ptr = a1;

do stuff with a_ptr

if (somecondition)
a_ptr = a2;

do more stuff with a_ptr

return a_ptr;
}

This is all fine and good.  But what happens if A is not a struct but a class? 
Well the pointer syntax becomes implied and immutable(A) means IMMUTABLE
reference variable pointing to immutable object which is *NOT WHAT IS NEEDED*.

There is no equivalent code to my knowledge that I can write in D that does the
EXACT same thing with class object variables that I just did with struct
pointers above while preserving the compiler's enforcment of the constness or
immutability of objects referenced by a1 and a2!  

Yes, I could have pointer variables pointing to object reference variables a1
and a2 which reference (implicitly point to without actual pointer syntax) the
actual heap objects; however, that double indirection (first explicit with
pointers and second implicit with the object reference variable) is inefficient
and somewhat confusing.  At worst, the D language, by its lacking the
appropriate constness-typing solution is actively encouraging the programmer to
simply cast away the constness or immutability of objects referenced by a1 and
a2 to gain the simplicity of storing reference to a1's object or a2's object in
a fully mutable reference variable (e.g. A a_ptr;)

THE SOLUTION:

The solution is two new keywords obj_const and obj_immutable or some
variation on those names which when applied as either a storage specifier (as
in obj_const ClassName variableName;) or as a type modifier (as in
obj_immutable(ClassName) variableName;) would create a MUTABLE REFERENCE
VARIABLE REFERRING TO A CONST OR IMMUTABLE CLASS OBJECT.

This would extend to declaring arrays of mutable references to const or
immutable objects like so

obj_const(ClassName)[] myArray;

myArray.length = 2;

immutable ClassName immutableRef = cast(immutable) new
ClassName(argument);
const ClassName constRef = new ClassName(argument);

obj_const ClassName myMutableRef = immutableRef;

myArray[0] = myMutableRef;

myMutableRef = constRef;

myArray[1] = myMutableRef

This new functionality would be backwards compatible with the existing meaning
of const(ClassName) and immutable(ClassName) which would continue to
declare an un-modifiable reference variable pointing to a const or immutable
class object.

The only compatibility issue I can see is with variables, types, and functions
clashing with the new keywords, which I expect would be unheard of, given the
highly specific nature of these keywords; it is very unlikely for there to be
any significant name clashes.

POSSIBLE KEYWORDS:

objconst, objimmutable
obj_const, obj_immutable
tailconst, tailimmutable
tail_const, tail_immutable

CONCLUSION:

Hopefully, these additions can add to the expressiveness and power of the D
language and increase the ability of the compiler to enforce constness and
immutability in ways that are useful to the programmer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5984] add new keywords obj_const and obj_immutable to make it possible to declare mutable reference variables referencing const or immutable class instances

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5984


kenn...@gmail.com changed:

   What|Removed |Added

 CC||kenn...@gmail.com


--- Comment #1 from kenn...@gmail.com 2011-05-11 13:19:54 PDT ---
How is this better than the 'const(Object) ref' syntax*?

class A { ... }

immutable(A) func(immutable A a1, immutable A a2) {
immutable(A) ref a_ptr = null;
...
}

and

const(ClassName)ref[] myArray;

Actually there is already std.typecons.Rebindable which mostly works (uglily):

class A { ... }

immutable(A) func(immutable A a1, immutable A a2) {
Rebindable!(immutable(A)) a_ptr = null;
...
}

and

Rebindable!(const(ClassName))[] myArray;
myArray.length = 1;
myArray[0] = constant_object;
myArray ~= rebindable(constant_object);

*: https://github.com/D-Programming-Language/dmd/pull/3

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5881] New: Spellchecker should include built-in keywords

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5881

   Summary: Spellchecker should include built-in keywords
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: diagnostic
  Severity: enhancement
  Priority: P4
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com


--- Comment #0 from kenn...@gmail.com 2011-04-24 13:40:42 PDT ---
The spellchecker in DMD currently only checks for custom identifiers. But is it
possible to misspell built-in keywords as well, e.g.

  pramga(msg, x);
//   ^^

Perhaps the spellchecker could include the keywords to the look-up list as
well.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---