[#53097] [ruby-trunk - Bug #8000][Open] "require 'tk'" segfaults on 64-bit linux with Tk 8.6 — "edmccard (Ed McCardell)" <edmccard@...>
25 messages
2013/03/02
[#53199] [ruby-trunk - Bug #8040][Open] Unexpect behavior when using keyword arguments — "pabloh (Pablo Herrero)" <pablodherrero@...>
11 messages
2013/03/07
[#53203] [ruby-trunk - Feature #8042][Open] Add Addrinfo#socket to create a socket that is not connected or bound — "drbrain (Eric Hodel)" <drbrain@...7.net>
12 messages
2013/03/07
[#55610] [ruby-trunk - Feature #8042] Add Addrinfo#socket to create a socket that is not connected or bound
— "headius (Charles Nutter)" <headius@...>
2013/06/23
[#53211] [ruby-trunk - Feature #8046][Open] allow Object#extend to take a block — "phluid61 (Matthew Kerwin)" <matthew@...>
6 messages
2013/03/08
[#53248] Github commit log should not be used as references on redmine — Marc-Andre Lafortune <ruby-core-mailing-list@...>
Github commit log should not be used as references on redmine. E.g:
10 messages
2013/03/09
[#53249] Re: Github commit log should not be used as references on redmine
— Zachary Scott <zachary@...>
2013/03/09
I think redmine should ignore flags like \[GH.*#\d*\] or something similar.
[#53606] Re: Github commit log should not be used as references on redmine
— Zachary Scott <zachary@...>
2013/03/21
Ping!
[#53615] Re: Github commit log should not be used as references on redmine
— "NARUSE, Yui" <naruse@...>
2013/03/22
The best place of creating Feature Requests for bug.ruby-lang.org's Redmine
[#53265] [ruby-trunk - Bug #8058][Open] RubyGems test failures under MinGW — "luislavena (Luis Lavena)" <luislavena@...>
5 messages
2013/03/09
[#53349] [ruby-trunk - Bug #8080][Open] Segfault in rb_fd_set — "jonleighton (Jon Leighton)" <j@...>
8 messages
2013/03/12
[#53386] [CommonRuby - Feature #8088][Open] Method#parameters (and friends) should provide useful information about core methods — "headius (Charles Nutter)" <headius@...>
14 messages
2013/03/13
[#55921] [CommonRuby - Feature #8088] Method#parameters (and friends) should provide useful information about core methods
— "headius (Charles Nutter)" <headius@...>
2013/07/10
[#55922] Re: [CommonRuby - Feature #8088] Method#parameters (and friends) should provide useful information about core methods
— Yorick Peterse <yorickpeterse@...>
2013/07/10
Consider the following code:
[#55926] Re: [CommonRuby - Feature #8088] Method#parameters (and friends) should provide useful information about core methods
— Charles Oliver Nutter <headius@...>
2013/07/10
On Wed, Jul 10, 2013 at 11:16 AM, Yorick Peterse
[#53412] [CommonRuby - Feature #8096][Open] introduce Time.current_timestamp — "vipulnsward (Vipul Amler)" <vipulnsward@...>
34 messages
2013/03/14
[#53461] [CommonRuby - Feature #8096] introduce Time.current_timestamp
— "vipulnsward (Vipul Amler)" <vipulnsward@...>
2013/03/15
[#53478] [ruby-trunk - Feature #8107][Open] [patch] runtime flag to track object allocation metadata — "tmm1 (Aman Gupta)" <ruby@...1.net>
20 messages
2013/03/16
[#53526] [ruby-trunk - Feature #8107] [patch] runtime flag to track object allocation metadata
— "tmm1 (Aman Gupta)" <ruby@...1.net>
2013/03/19
[#53523] [ruby-trunk - Bug #8122][Open] [patch] gc: GC.stat improvements and related cleanup — "tmm1 (Aman Gupta)" <ruby@...1.net>
5 messages
2013/03/19
[#53585] Consistent hashing in the face of HashDOS? — Charles Oliver Nutter <headius@...>
It had to happen eventually...
7 messages
2013/03/21
[#53599] [Backport 200 - Backport #8135][Open] Backport escape all closing parens - r39858 — "vo.x (Vit Ondruch)" <v.ondruch@...>
7 messages
2013/03/21
[#53619] [ruby-trunk - Bug #8142][Open] [patch] iseq: reduce array allocations for simple sequences — "tmm1 (Aman Gupta)" <ruby@...1.net>
7 messages
2013/03/22
[#53635] [ruby-trunk - Bug #8148][Open] [patch] reduce allocations due to __FILE__ and {class,module}_eval — "tmm1 (Aman Gupta)" <ruby@...1.net>
6 messages
2013/03/22
[#54391] [ruby-trunk - Bug #8148] [patch] reduce allocations due to __FILE__ and {class,module}_eval
— "headius (Charles Nutter)" <headius@...>
2013/04/17
[#53679] Why doesn’t String#+ return an untrusted result if self or other is untrusted? — Nikolai Weibull <now@...>
Hi!
5 messages
2013/03/23
[#53680] Re: [ruby-core:53679] Why doesn’t String#+ return an untrusted result if self or other is untrusted?
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/03/23
On Sat, Mar 23, 2013 at 2:45 PM, Nikolai Weibull <now@bitwi.se> wrote:
[#53685] Re: [ruby-core:53680] Re: [ruby-core:53679] Why doesn’t String#+ return an untrusted result if self or other is untrusted?
— Nikolai Weibull <now@...>
2013/03/23
On Sat, Mar 23, 2013 at 8:30 PM, KOSAKI Motohiro
[#53688] [ruby-trunk - Feature #8158][Open] lightweight structure for loaded features index — "funny_falcon (Yura Sokolov)" <funny.falcon@...>
27 messages
2013/03/24
[#53692] [ruby-trunk - Bug #8159][Open] Build failure introduced by Rinda changes — "luislavena (Luis Lavena)" <luislavena@...>
22 messages
2013/03/24
[#53713] [ruby-trunk - Bug #8159] Build failure introduced by Rinda changes
— "naruse (Yui NARUSE)" <naruse@...>
2013/03/25
[#53709] [Backport 200 - Backport #8163][Assigned] Backport r39919 — "authorNari (Narihiro Nakamura)" <authorNari@...>
6 messages
2013/03/25
[#53733] [ruby-trunk - Bug #8165][Open] Problems with require — "Krugloff (Alexandr Kruglov)" <mr.krugloff@...>
12 messages
2013/03/26
[#53764] [ruby-trunk - Bug #8173][Open] 2-arg form of Time.at can take a Time as either argument — "hasari (Hiro Asari)" <asari.ruby@...>
8 messages
2013/03/27
[#53808] [ruby-trunk - Feature #8181][Open] New flag for strftime that supports adding ordinal suffixes to numbers — "tkellen (Tyler Kellen)" <tyler@...>
10 messages
2013/03/28
[#53811] [ruby-trunk - Bug #8182][Open] XMLRPC request fails with "Wrong size. Was 31564, should be 1501" — "tsagadar (Marcel Mueller)" <marcel.mueller@...>
28 messages
2013/03/28
[#53825] Thread/fork issue — Jason Gladish <jason@...>
Hello all,
9 messages
2013/03/29
[#53832] Re: Thread/fork issue
— Tanaka Akira <akr@...>
2013/03/29
2013/3/30 Jason Gladish <jason@expectedbehavior.com>:
[#53887] Re: Thread/fork issue
— Tanaka Akira <akr@...>
2013/04/02
2013/3/30 Tanaka Akira <akr@fsij.org>:
[#53901] Re: Thread/fork issue
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/04/02
> I wrote a simple script to reproduce the problem.
[#53849] [ruby-trunk - Feature #8191][Open] Short-hand syntax for duck-typing — "wardrop (Tom Wardrop)" <tom@...>
48 messages
2013/03/31
[#53894] [ruby-trunk - Feature #8191] Short-hand syntax for duck-typing
— "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>
2013/04/02
[#53938] [ruby-trunk - Feature #8191] Short-hand syntax for duck-typing
— "phluid61 (Matthew Kerwin)" <matthew@...>
2013/04/03
[#53916] [ruby-trunk - Feature #8191] Short-hand syntax for duck-typing
— "wardrop (Tom Wardrop)" <tom@...>
2013/04/03
[#53850] An evaluation of 2.0.0 release — Yusuke Endoh <mame@...>
Let's look back at 2.0.0 release so that we can do better next time.
12 messages
2013/03/31
[#53853] Re: An evaluation of 2.0.0 release
— V咜 Ondruch <v.ondruch@...>
2013/03/31
Hello Yusuke,
[ruby-core:53383] [CommonRuby - Feature #7701] Non-optional (required) keyword args
From:
"headius (Charles Nutter)" <headius@...>
Date:
2013-03-13 19:55:54 UTC
List:
ruby-core #53383
Issue #7701 has been updated by headius (Charles Nutter).
trans (Thomas Sawyer) wrote:
> Wait. You are the one who brought it up in #16. I was just responding to that.
mame brought it up in #9.
> I agree for the opposite reason! Why the rush to add required keyword arguments when Ruby took, jeez, how many years, to get keyword arguments? Wouldn't it be prudent to give it some time first?
Because they should have been there to begin with?
> Really? That's what you got from what I wrote? Well, try reading what I wrote again. If you want a summary, I suppose the closest common description is YAGNI.
I think the +1s on this bug indicate people do want it. Whether they need it remains to be seen.
> > def foo(a:, b:) .... end
> > foo(1) => ArgumentError("Method `foo' requires arguments `a', `b'")
> > Bad thing?
>
> Yes.
Arguing against a feature solely based on YAGNI doesn't seem very effective. Your other arguments were better because they actually discuss concerns about the feature, rather than just saying "I don't think this will be useful, so let's not do it." Do you have other substantive concerns about the feature itself?
I think having required and optional kwargs goes nicely with required and optional positional args, and I personally think it will see good use in DSLs and more readable APIs. For the same reason optional kwargs are useful to have in Ruby 2.0, required kwargs provide the same benefits *plus* guarantees that you'll receive certain keywords. It's the naming+positional flexibility of kwargs with the strictness of required positional args.
In short, I'll summarize my rebuttal this way: Do you agree that keyword args are useful? Do you agree that being able to force certain args to be given is useful? Then why wouldn't required keyword args be a natural feature to have in place?
----------------------------------------
Feature #7701: Non-optional (required) keyword args
https://bugs.ruby-lang.org/issues/7701#change-37580
Author: headius (Charles Nutter)
Status: Assigned
Priority: Normal
Assignee: nobu (Nobuyoshi Nakada)
Category:
Target version:
=begin
I would like to see keyword args expanded to include a non-optional form, to force callers to pass in keyword arguments.
Currently, we have required, optional, and rest positional args but only optional and rest keyword args. Consistency is one small reason to add required keyword args.
They would likely take the form of keyword with no default value:
def foo(a:, b:)
...
end
foo(a: 1, b: 2) # ok
foo(a: 1) # ArgumentError
Justifications:
* Consistency with positional args. A weak justification, I know.
* Avoiding a lot of boilerplate code by users wishing to enforce keywords being passed in. Example from tenderlove:
def foo(a: raise('pass a'), b: raise('pass b'))
* Building a rich API atop keyword args would be easier (i.e. require fewer manual checks) if you could force some keywords to be passed in. Having to check everywhere when you require a keyword argument is unpleasant.
* Keyword args already enforces that no *additional* keyword args can be passed (without **), and it seems lopsided to have no way to enforce a minimum set of keyword args.
=end
--
http://bugs.ruby-lang.org/