Decide whether -*- should be required for frozen_string_literal magic comments [Feature #8976]

naruse: vim’s indicator is “vim: …”

nobu: should be have an indicator of pragrma.

matz: why?

nobu: to avoid misunderstanding with comments.

matz: nobody care about that.

nobu: line should not include any other information.

matz: i agree with it.


matz: i don’t want to recommend indicators.

nobu: sould we remove indicators?

akr: should remain indicators to keep compatibility.

ko1: only coding pragma?

nobu: we have warn-indnent pragmra.

naruse: warn-indent is in 2010

nobu: i’ll make it to keep compatibility.


naruse: should we put pragmas in one line? or multi-lines?

akr: there are possibilities to increase pragma, so that shold accept multi-lines.

matz: i do not care about multi-lines.

akr: people may want to write copyright early.

naruse: people may want to write a comment for pragmas


akr: how about dynamic strings “foo#{bar}baz”?

nobu: how about “#{‘baz’}”?

ko1: it is easy to understand all “...” is frozen. Shugo-san’s first comment is for “compatibility”.

matz: i agree to

matz: i have another idea +“...” -> mutable, -”...” -> immutable. it is more clean than “...”.freeze. how about that, instead of the magic comment? i don’t care about pull-requests, but care about the representation of source code.

akr: …

matz: I don’t like magic comment, so that I hesitate to introduce it.

a_matsuda: + and - seems string operation.  << -”foo” can be seen as a here document.

matz: I understand.  + and - is not good idea.

matz: another idea: make ‘’’foo’’’ frozen.  incompatibility is negligible.

matz: yet another idea: make single quoted strings frozen. This is incompatible.


akr: should we separate this topic to another ticket? this is “how to write a pragmra”.

ko1: we should describe syntax of “how to write pragmas”

matz: I don’t like pragmas but if it is required

ko1: this pragma is for experimental feature. if we decide to reject default frozen string literal, then you remove this pragma, or remain this pragma?

matz: i will remain it.


→ traversal framework?

inspect に引数を渡したい

→ inspect2? not clean.

naruse: On 1.9 I tried to implement such logic, but I gave  up and use Encoding.default_internal/Encoding.default_external


nobu: syntax fixed? there are 3 possibilities.

obj.?foo =>

  1. obj != nil ? : nil
  2. obj.respond_to?(:foo) ? : obj
  3. obj.respond_to?(:foo) ? : nil

matz: 1.

akr: accepted?

matz: i’m not sure now.

akr: obj.&foo, obj.&&foo is proposed. how about it?

matz: i can accept original proposal.

[ruby-core:70854] [Ruby trunk - Feature #11537]


C# Design Notes for Sep 8, 2015

?a syntax

matz: I want to deprecate it

akr: If people aren’t in trouble, it should be kept because of compatibility

class String

  def +@



  def -@




str = ''



p str

str = ''

puts <<-'foo'



p str

str = ''

puts = 'bar'

puts <<-'foo'



p str

irb(main):007:0> puts <<-'foo'

irb(main):008:0' hello

irb(main):009:0' foo


=> nil

current option:

  1. magic comment
  2. +/- (=> not bad, ex: str = <<-’foo’ # here document?) => “””...”””, “””...”
  3. ‘...’ to freeze

other ideas:

  1. :foo -> frozen string
  2. :’foo’ -> frozen string
  3. :foo:
  4. %f{...}
  5. ?x -> frozen
  6. ?’...’ -> frozen(syntax extend)

str = ?’foo’

str = !’foo’ -> bad idea (ex: str = !’foo’.start_with(‘f’))

matz; how about to warn for “initialise”?

akr: found 3 cases and 1 case uses “initialise” intentionaly.


11/9 (mon) 14:00 (JST)-

@SFDC Tokyo